Sunucusuz bilişim, altyapı yönetimi derdini ortadan kaldırarak yazılım dünyasında bir özgürlük çağı başlattı. Ancak 2025 itibarıyla bulut ortamlarının %54'ünde internete açık ve hassas veri içeren VM ve serverless örnekleri tespit edildi (
Wiz 2025 Cloud Data Security Report, 2025). Bu özgürlüğün bir bedeli var: Sunucular görünmez olduğunda onları korumak için ezberlediğimiz geleneksel yöntemler geçersizleşiyor. Bulut ortamlarındaki güvenlik hatalarının %95'i insan kaynaklı yanlış yapılandırmalardan kaynaklanıyor (
SentinelOne 2026 Bulut Güvenliği İstatistikleri, 2026) ve AWS Lambda bu riskten muaf değil.
AWS Lambda'nın güvenlik modeli, klasik "çevre güvenliği" anlayışından tamamen kimlik ve kod bütünlüğü temeline kaymış durumda. Bu rehberde Lambda'nın iç mimarisinden IAM rollerine, gizli bilgi yönetiminden ağ izolasyonuna kadar bulut güvenliği uzmanlarının uykularını kaçıran detayları ele alıyoruz.
- Bulut ortamlarında verilen IAM izinlerinin %98'i hiç kullanılmıyor, bu da aşırı yetkili fonksiyonların patlama yarıçapını büyütüyor (
Sysdig 2024 Raporu, 2024). /tmpdizini aynı yürütme ortamında sıcak başlangıçlar arasında kalıcıdır; hassas dosyaların işlendikten sonra silinmemesi veri sızıntısına yol açabilir.- Lambda'nın
GetFunctionAPI'si, fonksiyon kod paketini indirmek için pre-signed URL döndürür; sabit kodlanmış anahtarlar dakikalar içinde ele geçirilebilir. - Kritik fonksiyonlara ayrılmış eşzamanlılık tanımlamak, DoS saldırıları sırasında güvenlik izleme sistemlerinin çalışmaya devam etmesini sağlar.
1. Lambda Hücresinin Anatomisi: Paylaşımlı Sorumluluğun Sınırları?
Bulut güvenliğinin temel taşı olan paylaşımlı sorumluluk modeli Lambda'da en uç noktaya ulaşır. AWS, Firecracker mikro VM'lerle izole edilmiş geçici bir ortam sunar; çalışma zamanını, işletim sistemini ve ağı yönetir. Ancak bu kutuya ne kod yazdığınız, hangi yetkileri verdiğiniz ve gelen veriyi nasıl karşıladığınız tamamen sizin sorumluluğunuzdadır.
Buradaki en büyük yanılgı, sandbox ortamının kusursuz olduğu varsayımıdır. Bir Lambda fonksiyonu sonlandığında /tmp dizindeki veriler silinir, ancak aynı yürütme ortamı sıcak tutulup başka bir çağrı için kullanılırsa, önceki çağrıda /tmp altına yazılan dosyalar otomatik olarak temizlenmez. Hassas bir dosyanın sonraki çağrı tarafından okunması mümkün olabilir. Bu nedenle kodunuzu durumsuz yazmak ve hassas verileri asla /tmp'ye kalıcı olarak bırakmamak en büyük güvenlik prensibinizdir.
Atıf Kapsülü: AWS Firecracker mikro VM'leri her çağrıda bellek izolasyonu sağlar, ancak /tmp dizini aynı yürütme ortamında sıcak başlangıçlar arasında kalıcıdır (
AWS Lambda Güvenlik Dokümantasyonu, 2024). Bu nedenle durumsuz kod yazmak ve hassas dosyaları işlendikten hemen sonra silmek, veri sızıntısını önlemenin tek yoludur.
2. IAM Labirenti: En Az Yetkiyi Vermenin Kritik Önemi?
Bulut ortamlarında verilen tüm izinlerin yalnızca %2'si aktif olarak kullanılıyor (Sysdig 2024 Raporu, 2024). Bu şu anlama geliyor: Lambda fonksiyonlarının büyük çoğunluğu hiç ihtiyaç duymadığı yetkilerle dolaşıyor. Lambda'nın en kritik güvenlik yapılandırması olan IAM Execution Role, kodunuzun AWS ekosisteminde neler yapabileceğini belirler. Bir saldırganın hayali, "*" yetkisine sahip bir Lambda'yı ele geçirip bu rolü kötüye kullanmaktır.
Ölümcül Senaryo: Kullanıcıların profil fotoğraflarını S3'e yükleyen bir Lambda fonksiyonunuz olsun. Bu fonksiyonun rolüne yalnızca s3:PutObject yetkisi vermeniz gerekirken, test kolaylığı bahanesiyle s3:* veya AdministratorAccess tanımlarsanız, kodunuzdaki bir yol atlatma (path traversal) açığı saldırganın tüm S3 bucket'larınızı listelemesine ve silmesine olanak tanır.
Tipik Bir Denetim Senaryosu: Yaygın olarak karşılaşılan bir durumda, bir Lambda fonksiyonunun dynamodb:* yetkisine sahip olduğu tespit edildi. Oysa fonksiyon yalnızca tek bir tabloya yazma yapıyordu. Yetki dynamodb:PutItem ile o tabloya kısıtlandığında hata yönetimi mekanizması bozuldu; geliştirici daha önce hata almamak için yetkileri geçici olarak yükseltmiş ve unutmuştu. Bu, en az yetki prensibinin ihmal edilmesinin tipik bir örneğidir.
Pratik Savunma: IAM rollerini Resource ve Condition bloklarıyla olabildiğince daraltın. Örneğin yalnızca belirli bir bucket'a ve belirli bir prefix'e yazma izni verin. Condition ile yalnızca belirli VPC'den gelen çağrılara izin verin. Joker karakter * kullanımını CI/CD pipeline'ınızda otomatik taramalarla engelleyin.
Atıf Kapsülü: 2024 Sysdig raporuna göre bulut ortamlarında verilen IAM izinlerinin %98'i hiç kullanılmıyor (Sysdig, 2024). Bu durum, Lambda fonksiyonlarının neredeyse tamamının en az yetki prensibine aykırı yapılandırıldığını ve olası bir ihlalde saldırganın eline gereksiz yere geniş bir yetki seti geçeceğini gösteriyor.
3. Tetikleyici Çığları ve Olay Enjeksiyon Tehditleri?
Lambda'nın doğası olay güdümlüdür. Bir S3 bucket'ına dosya yüklenmesi, bir API Gateway çağrısı veya bir SQS kuyruğuna mesaj düşmesi... Tüm bu olaylar Lambda'ya bir event nesnesi taşır. En büyük hata, bu event nesnesinin güvenilir olduğunu varsaymaktır.
Özellikle S3 tetikleyicilerinde durum kritiktir. Birisi bucket'ınıza malicious_file.jpg'; DROP TABLE users; -- adında bir dosya yüklediğinde, dosya adı doğrudan Lambda'nın event objesine gider. Bu dosya adını bir sistem komutunda veya SQL sorgusunda doğrudan kullanırsanız, komut enjeksiyonuna kapı açarsınız.
En basit çözüm, olay verisini işlemeden önce bir şema doğrulamasından geçirmektir. Beklediğiniz formatta olmayan hiçbir veri işlenmemelidir. Ayrıca fonksiyon kodunuzda hiçbir zaman kullanıcı girdisini doğrudan sistem komutuna veya SQL sorgusuna parametre olarak eklemeyin; her zaman parametreleştirilmiş sorgu kullanın.
Atıf Kapsülü: Event tetikleyicileri Lambda'nın en güçlü özelliği olsa da, doğrulanmamış girdi kabul etmek sunucusuz ortamlardaki en yaygın enjeksiyon açıklığıdır (
OWASP Serverless Top 10, 2024). Şema doğrulaması ve parametreleştirilmiş sorgular, bu saldırı yüzeyini kapatmanın en etkili iki yöntemidir.
4. Gizli Bilgiler Nerede Saklanmalı: Kod, Ortam Değişkeni ve Parametre Dükkanı?
Lambda güvenliğinin en kanayan yarasıdır: "Nasıl olsa kimse görmez" mantığıyla API anahtarlarını veya veritabanı bağlantı cümlelerini doğrudan koda gömmek. 2023 yılında GitHub'a 12.8 milyon gizli bilgi (secret) sızdırıldı; bu bir önceki yıla göre %28 artış anlamına geliyor (
GitGuardian 2024 Raporu, 2024). AWS Lambda da bu riskten muaf değil.
Kod İndirme Tehdidi: lambda:GetFunction API iznine sahip herhangi bir kimlik, fonksiyonun kaynak kod paketini indirmek için geçici bir S3 URL'si alabilir. Saldırgan bu ZIP dosyasını indirir ve grep ile tarar. Bir dakikadan kısa sürede tüm sabitlenmiş anahtarlara ulaşır.
Ortam Değişkenleri: Bekleme anında KMS ile şifrelenir. Ancak fonksiyon çalıştığı anda düz metin olarak belleğe yüklenir. Kodunuzda print(os.environ) gibi bir debug satırı bırakırsanız tüm sırlarınız CloudWatch Logs'a düşer. Log okuma yetkisi olan herkes bu verileri görebilir.
Doğru Çözüm: Parolalar, token'lar ve bağlantı cümleleri için AWS Secrets Manager veya SSM Parameter Store (SecureString) kullanın. Kod içinde bu servislere çalışma zamanında bağlanarak gizli bilgileri alın. Bu yöntem hem kodu hem de konfigürasyonu dışarıdan gelebilecek sızıntılara karşı korur.
Ortam değişkenleri yalnızca loglara yanlışlıkla yazdırıldığında değil, lambda:GetFunctionConfiguration API'si çağrıldığında da düz metin olarak döner. Bu API genellikle CI/CD araçlarına verilir ve gözden kaçan bir yetki genişlemesiyle tüm ortam değişkenleriniz okunabilir hale gelir.
Atıf Kapsülü: AWS Lambda ortam değişkenleri KMS ile şifrelense de, lambda:GetFunctionConfiguration API'si ve CloudWatch loglama yoluyla düz metin olarak ifşa olabilir (AWS Lambda API Referansı, 2024). Secrets Manager veya SSM Parameter Store kullanmak, gizli bilgileri hem koddan hem de ortam değişkenlerinden soyutlayarak bu riski ortadan kaldırır.
5. Ağ Labirentine Yolculuk: VPC İçinde ve Dışında Güvenlik?
Varsayılan olarak Lambda, AWS'nin kendi yönettiği genel bir ağda çalışır ve internete doğrudan çıkabilir. Ancak RDS veya ElastiCache gibi özel kaynaklara erişmek için Lambda'yı Sanal Özel Bulut'a bağlamanız gerekir.
Bu bağlantı sırasında Lambda'nın yürütme ortamına bir Elastic Network Interface bağlanır ve fonksiyonunuz özel bir IP alır. Güvenlik gruplarını yanlış yapılandırmak, saldırgana iç ağınızda bir atlama noktası kazandırır.
Burada dikkat edilmesi gereken temel nokta, Lambda'ya hem NAT üzerinden internete çıkış hem de veritabanına erişim verirken güvenlik grubu kurallarını mümkün olan en dar şekilde yazmaktır. Veritabanı portuna 0.0.0.0/0'dan erişime izin vermek tüm ağ izolasyonunu yok eder.
Atıf Kapsülü: AWS Lambda VPC entegrasyonu, her alt ağda bir ENI oluşturarak fonksiyonun özel kaynaklara erişmesini sağlar, ancak güvenlik gruplarının aşırı geniş tanımlanması, Lambda'yı iç ağa yönelik saldırılarda bir pivot noktası haline getirebilir (AWS VPC Dokümantasyonu, 2024).
6. Operasyonel Savaş Alanı: Eşzamanlılık ve Hizmet Reddi?
Lambda, varsayılan olarak bölge başına 1000 eşzamanlı yürütme limitiyle çalışır (AWS Lambda Kotaları, 2024). Bir saldırgan maliyetlerinizi şişirmek veya güvenlik izleme sistemlerinizi devre dışı bırakmak için bu limiti hedef alabilir.
Saldırgan saniyede binlerce istek göndererek bölgesel limitinizi doldurmayı hedefler. Başarılı olursa aynı hesaptaki meşru fonksiyonlarınız kısılmaya başlar. Kritik olan şu: Saldırı tespit ve engelleme mantığınız da Lambda'da çalışıyorsa kendinizi tamamen kör etmiş olursunuz.
Kalkanınız: Kritik öneme sahip fonksiyonlara (güvenlik, olay müdahalesi, sağlık kontrolü) ayrılmış eşzamanlılık tanımlayın. Böylece saldırı sırasında diğer fonksiyonlar kısılsa bile kritik olanlar çalışmaya devam eder. Bu, sunucusuz dünyada "kaynak garantisi" sağlamanın en etkili yoludur.
Atıf Kapsülü: AWS Lambda'da ayrılmış eşzamanlılık (reserved concurrency), belirli bir fonksiyonun kullanabileceği maksimum yürütme sayısını garanti altına alarak DoS saldırıları sırasında dahi kritik iş yüklerinin çalışmasını sürdürmesini sağlar (AWS Lambda Geliştirici Rehberi, 2024).
7. Tedarik Zinciri Tehditleri: Lambda Katmanları?
Ortak kod ve kütüphaneleri paylaşan Lambda Katmanları, geliştirme hızını artırırken sessiz bir tehdit de oluşturur. Katmanlar salt okunur olarak /opt dizinine bağlanır ve birden fazla fonksiyon tarafından kullanılır. Eğer CI/CD pipeline'ınızda bu katmanı güncelleyen mekanizma yeterince korunmuyorsa, saldırgan tek bir katman güncellemesiyle yüzlerce fonksiyona zararlı kod enjekte edebilir.
Lambda'nın yerleşik kod bütünlüğü kontrolleri genellikle doğrudan yüklenen ZIP dosyasına odaklanır; katman içeriğindeki küçük bir değişiklik fark edilmeyebilir. Ayrıca üçüncü parti katmanlar kullanıyorsanız, bu katmanların güncellemelerini düzenli olarak taramak ve bağımlılık güvenlik açıklarını denetlemek sizin sorumluluğunuzdadır.
Katmanların bir diğer az bilinen riski: lambda:PublishLayerVersion yetkisi genellikle geliştiricilere geniş kapsamlı verilir. Bu yetkiyi kötüye kullanan bir iç tehdit (veya çalınan bir credential), mevcut bir katmanın yeni bir sürümünü yayınlayarak tüm bağlı fonksiyonlara arka kapı yerleştirebilir.
8. Gözetim ve Tespit: Loglama ve İzleme Stratejisi?
Lambda güvenliğinin en çok ihmal edilen ayağı loglama ve izlemedir. Tüm Lambda fonksiyonları stdout ve stderr çıktılarını otomatik olarak CloudWatch Logs'a yazar; log grubu adı /aws/lambda/<fonksiyon-adi> formatındadır ve değiştirilemez. Bu loglar güvenlik olaylarını tespit etmek için en değerli kaynağınızdır, ancak aynı zamanda hassas veri sızdırmanın da en kolay yoludur.
Güvenlik İzleme İçin CloudWatch Logs: Lambda loglarınızı CloudWatch Logs Insights ile sorgulayarak anormal çağrı desenlerini, başarısız kimlik doğrulamalarını veya beklenmedik hata mesajlarını tespit edebilirsiniz. Örneğin, bir fonksiyonun normalden 10 kat fazla çağrıldığını veya yürütme süresinin aniden uzadığını fark etmek bir güvenlik olayının erken sinyali olabilir.
Hassas Veri Sızıntısına Karşı Filtreleme: print() veya console.log() ile yanlışlıkla loglanan API anahtarlarını, kredi kartı numaralarını veya kişisel verileri tespit etmek için CloudWatch Logs'ta veri koruma politikaları (data protection policies) tanımlayabilirsiniz. AWS, yerleşik olarak PII ve finansal veri desenlerini tarar ve ihlalleri maskeleyebilir.
CloudTrail Entegrasyonu: Lambda API çağrıları (fonksiyon oluşturma, güncelleme, silme, çağırma) AWS CloudTrail tarafından otomatik olarak kaydedilir. lambda:UpdateFunctionCode veya lambda:AddPermission gibi kritik API çağrılarını CloudTrail üzerinde alarm olarak tanımlamak, yetkisiz değişiklikleri dakikalar içinde tespit etmenizi sağlar.
Atıf Kapsülü: Bulut güvenlik ihlallerinin %31'i yanlış yapılandırmalardan kaynaklanırken, bunların büyük kısmı loglama ve izleme eksikliği nedeniyle haftalarca fark edilmez (
Cloud Security Alliance Top Threats, 2024). Lambda ortamında CloudWatch Logs ve CloudTrail entegrasyonu, tespit süresini dakikalara indirebilir.
Sonuç: Görünmez Olanı Savunmak
AWS Lambda, doğru yapılandırıldığında geleneksel sunuculardan çok daha güvenli olabilir çünkü saldırı yüzeyi küçülmüştür. Ancak yanlış yapılandırıldığında patlama yarıçapı bir o kadar büyük olur. Bulut ortamlarında verilen izinlerin %98'inin hiç kullanılmadığı düşünülürse, çoğu Lambda fonksiyonunun hala gereksiz risk taşıdığını söylemek yanlış olmaz.
Sunucusuz güvenlikte başarılı olmak için şu beş prensibi benimseyin:
- Asla Güvenme, Her Zaman Doğrula: Gelen olay verilerini kaynağından bağımsız olarak doğrula ve filtrele.
- En Az Yetkiyi Ver: IAM rollerini yazarken cimri olun. Kodun neye ihtiyacı varsa yalnızca onu verin.
- Kodunuzda Çıplak Sır Taşımayın: Ortam değişkenine bile güvenmeyin; Secrets Manager veya SSM Parameter Store kullanın.
- Görünürlüğü Kaybetmeyin: CloudWatch Logs ve CloudTrail entegrasyonunu mutlaka yapılandırın.
- Operasyonel Dayanıklılığı Unutmayın: Güvenlik fonksiyonlarınıza ayrılmış eşzamanlılık tanımlayın.
Sıkça Sorulan Sorular
Lambda ortam değişkenleri KMS ile şifreleniyor, yine de riskli mi?
Evet, çünkü şifreleme yalnızca bekleme anında geçerlidir. Fonksiyon çalıştığında ortam değişkenleri düz metin olarak belleğe yüklenir ve lambda:GetFunctionConfiguration API'si veya yanlışlıkla loglama yoluyla ifşa olabilir (AWS Lambda API Referansı, 2024). Hassas veriler için Secrets Manager kullanmak daha güvenlidir.
Lambda'ya VPC bağlamazsam güvenlik riski artar mı?
VPC dışında çalışan Lambda, AWS yönetimli genel bir ağ kullanır ve RDS gibi özel kaynaklara doğrudan erişemez. Bu varsayılan izolasyon bazı senaryolarda güvenlidir. Ancak özel kaynaklara erişim gerekiyorsa VPC bağlantısı zorunludur ve bu durumda güvenlik gruplarını en dar şekilde yapılandırmak kritiktir.
Eşzamanlılık limiti aşıldığında ne olur, veri kaybeder miyim?
Limit aşıldığında istekler kısıtlanır ancak asenkron çağrılar için AWS otomatik olarak kuyruğa alır ve tekrar dener. Senkron çağrılarda çağrıyı yapan taraf 429 Too Many Requests hatası alır; veri kaybı yaşanmaz ancak hizmet kesintisi olur (AWS Lambda Kotaları, 2024).
Lambda fonksiyon kodumu kimler indirebilir?
lambda:GetFunction iznine sahip herhangi bir IAM kimliği fonksiyonun kod paketini indirebilir. Bu nedenle bu izni yalnızca kesinlikle gerekli rollere vermeli ve hiçbir zaman lambda:* gibi geniş politikalar tanımlamamalısınız (AWS Lambda API Referansı, 2024).
Katman kullanmadan Lambda geliştirmek mümkün mü?
Evet, katmanlar tamamen opsiyoneldir. Özellikle güvenlik odaklı fonksiyonlarda bağımlılıkları doğrudan dağıtım paketine dahil etmek, katman kaynaklı tedarik zinciri riskini ortadan kaldırır. Katmanlar yalnızca kod tekrarını azaltmak ve dağıtım boyutunu küçültmek için kullanılmalıdır.
Kaynakça
- AWS. (2024). AWS Lambda Güvenlik Dokümantasyonu. AWS
- AWS. (2024). AWS Lambda Geliştirici Rehberi. AWS
- AWS. (2024). Lambda Fonksiyon Yapılandırması - Eşzamanlılık. AWS
- AWS. (2024). Lambda API Referansı. AWS
- OWASP. (2024). Sunucusuz En İyi 10. OWASP
- Cloud Security Alliance. (2024). En Büyük Bulut Tehditleri. CSA
- Sysdig. (2024). 2024 Bulut Yerel Güvenlik Raporu. Sysdig
- Wiz. (2025). 2025 Cloud Data Security Report. Wiz
- GitGuardian. (2024). 2024 Gizli Bilgi Sızıntısı Raporu. GitGuardian
- SentinelOne. (2026). Bulut Güvenliği İstatistikleri. SentinelOne
Comments