1. Serverless/FaaS Nedir?
Serverless/FaaS, altyapı kapasitesini ve çalıştırma ortamını büyük ölçüde sağlayıcıya bırakarak “fonksiyon odaklı” geliştirmeyi mümkün kılar. Klasik sunucuda sizin yönettiğiniz birçok katman (OS patch, runtime scaling) cloud’a kayar. Ancak uygulama güvenliğinin büyük kısmı hâlâ sizdedir.
Serverless (FaaS) güvenliği nedir, klasik sunucudan farkı nedir?
Serverless güvenliği; fonksiyonların IAM yetkilerini, secrets’lerini, event tetikleyicilerini ve log/izlenebilirliğini doğru kurgulamaktır. Klasik sunucuda OS ve servis güvenliği daha çok sizin omuzunuzdadır; serverless’ta OS yönetimi azalır ama “kimlik, yetki ve event” riskleri artar. Yani güvenlik sorumluluğu ortadan kalkmaz, şekil değiştirir.
Shared responsibility (paylaşılan sorumluluk) çerçevesi
- •Cloud: altyapı, fiziksel güvenlik, bazı managed servis kontrolleri
- •Siz: IAM policy, secrets, uygulama kodu, event doğrulama, loglama, veri erişim sınırları
☑ Mini Check : Yanılgı kontrolü
- •“Cloud halleder” varsayımıyla IAM geniş mi?
- •Secrets’ler env var’da açık metin mi?
- •Event kaynakları sınırsız tetiklenebiliyor mu?
- •Log/trace yok mu, hata anında kör müsünüz?
- •KVKK açısından erişim logları saklanıyor mu?
Ne yapmalıyım?
- • Shared responsibility’i ekipte yazılı hale getir.
- • IAM’i fonksiyon bazında daralt (least privilege).
- • Secrets’i vault/KMS benzeri güvenli sistemde yönet.
- • Event kaynaklarını doğrula ve rate limit uygula.
2. Klasik Sunucu Modelinden Farkları
Serverless’ta ölçekleme ve kapasite yönetimi farklı çalışır; bu farklar hem performans hem güvenlik açısından yeni risk vektörleri yaratır.
Cold start, concurrency ve “beklenmeyen maliyet/limit” etkisi
- •Cold start: gecikme, timeouts
- •Concurrency: aynı anda çok çağrı → downstream servisleri boğma
- •Rate limit yoksa event flood → maliyet ve kesinti
Fonksiyonların parçalı yapısı ve görünürlük ihtiyacı
Çok fonksiyonlu mimaride, “tek yerde log” yaklaşımı kaybolur. Observability (log/metric/trace) olmadan incident yönetimi zorlaşır.
☑ Mini Check : Operasyonel risk
- •Fonksiyonların timeout/concurrency limitleri tanımlı mı?
- •Downstream (DB/PMS/CRM) korunuyor mu?
- •Cold start etkisi ölçülüyor mu?
- •Event flood senaryosu planlandı mı?
- •Alarm/incident akışı var mı?
Ne yapmalıyım?
- • Concurrency ve timeout sınırlarını yaz ve test et.
- • Downstream servisler için rate limit/throttle stratejisi kur.
- • Cold start ölçümünü KPI setine ekle.
- • Monitoring + incident sürecini serverless’a uyarlayın.
3. En Sık Karşılaşılan Güvenlik Riskleri (Yetki, Secrets, Event Tabanlı Saldırılar)
Serverless’ta üç ana risk kümesi öne çıkar: IAM yetki şişmesi, secrets sızıntısı ve event-driven saldırı yüzeyi.
Fonksiyon bazlı yetkilendirme (least privilege IAM)
En yaygın hata: “fonksiyon çalışsın” diye geniş policy vermek. Bu, ele geçirilen fonksiyonun etki alanını büyütür.
Çevresel değişkenler ve secrets güvenliği
Env var pratik ama risklidir; yanlış loglanır, yanlış paylaşılır, yanlış yetkiyle okunur. Secrets, güvenli saklama/dağıtım modeline taşınmalıdır.
Event tabanlı saldırılar serverless fonksiyonlarını nasıl etkiler?
Event-driven saldırılarda saldırgan, HTTP/cron/queue/bucket gibi event kaynaklarını flood ederek fonksiyonları aşırı tetikleyebilir. Bu hem maliyet hem kesinti riski doğurur; ayrıca doğrulama eksikse kötü niyetli payload ile iş mantığı istismar edilebilir. Çözüm; event doğrulama, rate limit, idempotency ve downstream korumasıdır.
Fark yaratan mini bölüm (Competitor Gap): “Güvenlik sorumluluğu cloud’da” yanılgısı
Serverless yaygınlaştıkça en büyük problem teknik değil, zihniyet: IAM/secrets/event kontrolü ihmal edildiğinde “sunucusuz” mimari daha da kırılgan hale gelir. Bu rehberin farkı, bu sınırları netleştirip uygulanabilir kontrol listesine bağlamasıdır.
☑ Mini Check : Serverless güvenlik çekirdeği
- •Her fonksiyonun IAM policy’si minimal mi?
- •Secrets env var yerine güvenli sistemde mi?
- •Event kaynaklarında doğrulama ve limit var mı?
- •İstekler idempotent mi (tekrar tetiklenince)?
- •Loglarda secret masking var mı?
Ne yapmalıyım?
- • Fonksiyonları “permission boundary” ile daralt.
- • Secrets’i vault/KMS modeline al; rotation planı kur.
- • Event kaynaklarına rate limit + doğrulama koy.
- • İdempotency ve retry stratejisini tasarla; flood etkisini azalt.
4. Loglama ve İzlenebilirlik
Serverless’ta görünürlük, güvenliğin ve operasyonun merkezidir: hangi event geldi, hangi fonksiyon ne yaptı, hangi hatayı verdi? Bu sorular cevaplanmadan incident yönetimi zayıflar.
Minimum observability seti
- •Request id / correlation id
- •Error rate, timeout, retry sayısı
- •Concurrency ve cold start metrikleri
- •Audit log: kim, hangi fonksiyonu deploy etti/kim erişti?
KVKK bağlamı
Rezervasyon/lead içeren fonksiyonlarda loglarda gereksiz kişisel veri tutulmamalı; erişim logları teknik tedbir kanıtı olarak saklanmalıdır. (Internal link: /tr/raporlama/kvkk-veri-guvenligi)
☑ Mini Check : İzlenebilirlik
- •Correlation id var mı?
- •Timeout/retry metrikleri izleniyor mu?
- •Concurrency/cold start ölçülüyor mu?
- •Audit log ve deploy kayıtları var mı?
- •KVKK veri minimizasyonu uygulanıyor mu?
Ne yapmalıyım?
- • Fonksiyonlara standart log şeması koy (request id).
- • Error/timeout/retry’ı alarm setine bağla.
- • Deploy değişikliklerini audit’le.
- • KVKK için log minimizasyonu + erişim kontrolü uygula.
5. Otel ve B2B İçin Serverless Senaryoları
Serverless her yerde “en iyi” değil; bazı yerlerde çok mantıklı, bazı yerlerde risklidir. Burada karar kriteri: kritik akış, latency hassasiyeti, entegrasyon güvenliği ve gözlemlenebilirlik olgunluğu.
Otel örnekleri
- •Rezervasyon raporlama fonksiyonları (batch)
- •Kampanya/lead işleme (webhook)
- •Sezon öncesi kapasite raporları (cron)
- •Riskli alan: checkout/ödeme gibi latency ve güvenlik kritik, event flood’a hassas uçlar (çok sıkı kontrol gerekir)
B2B örnekleri
- •Webhook alıcıları, entegrasyon dönüştürme (ETL)
- •Batch job ve export üretimi
- •API gateway arkasında küçük işlevler
- •Riskli alan: multi-tenant veri izolasyonu zayıfsa, geniş IAM ile çalışan fonksiyonlar
Otel ve B2B için serverless nerede mantıklı, nerede riskli?
Mantıklı: event tabanlı, burst yükleri olan, iyi izlenebilir ve sınırlandırılabilir işlerde (webhook, batch, rapor). Riskli: çok kritik ve yüksek yetkili, latency hassas işlemlerde; IAM/secrets/event kontrolleri olgun değilse. Karar, shared responsibility ve kontrol olgunluğuna göre verilmelidir.
☑ Mini Check : Kullanım kararı
- •Kritik fonksiyonlar için IAM minimal mi?
- •Event flood’a karşı rate limit/throttle var mı?
- •Downstream koruması var mı (DB/PMS/CRM)?
- •Observability yeterli mi?
- •KVKK risk analizi yapıldı mı (rezervasyon/lead)?
Ne yapmalıyım?
- • Serverless’ı “kritik olmayan/ölçekli” işlerde pilotla.
- • Kritik işlerde önce IAM+secrets+event kontrol olgunluğunu tamamla.
- • Rate limit/throttle ve idempotency’yi standart yap.
- • Loglama ve hata yönetimini sunucu güvenliği ve KVKK ile uyumlu kur (Internal link: /tr/yazilim/sunucu-guvenlik, /tr/raporlama/kvkk-veri-guvenligi).
6. İçerik içi tablo (IAM policy ve event kaynakları örnekleri)
| Bileşen | Risk | Kontrol (çerçeve) | Not |
|---|---|---|---|
| Function IAM | Yetki şişmesi | Least privilege + rol bazlı | Her fonksiyon ayrı policy |
| Secrets | Sızıntı | Vault/KMS + rotation | Env var’da açık metin yok |
| HTTP event | Flood/abuse | Rate limit + auth | API gateway policy |
| Queue/cron | Tetikleme patlaması | Concurrency limit + idempotency | Retry kontrollü |
| Storage event | Beklenmeyen payload | Doğrulama + allowlist | Bucket policy sıkı |
7. Serverless Fonksiyonlar İçin IAM & Secrets Güvenlik Checklist Şablonunu İndir
Serverless Fonksiyonlar İçin IAM & Secrets Güvenlik Checklist Şablonunu İndir — Yazılım / Sunucu ve Güvenlik (v1.0)
Bu asset; serverless fonksiyonlarda güvenliğin kritik üçlüsünü (IAM, secrets, event kaynakları) standartlaştırmak için hazırlanmıştır. Amaç; “cloud halleder” yanılgısını bitirip paylaşılan sorumluluk sınırlarını teknik olarak netleştirmektir. Loglama/audit yaklaşımını KVKK teknik tedbirleriyle uyumlu hale getirecek kontrol maddelerini de içerir.
Kim Kullanır?
DevOps/Backend, platform ekibi, otel/B2B entegrasyon ekipleri.
Nasıl Kullanılır?
- Fonksiyon envanterini çıkar ve her fonksiyonun IAM/secrets/event kaynaklarını yaz.
- Least privilege policy ve secrets saklama modelini uygula.
- Event doğrulama/rate limit ve observability ile drift/abuse riskini izle.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Her fonksiyon için ayrı IAM policy var
- ▢ ✅ Policy’ler least privilege (minimum action/resource)
- ▢ ✅ Secrets env var’da açık metin değil (vault/KMS)
- ▢ ✅ Secrets rotation + revocation planı var
- ▢ ✅ Event kaynakları allowlist + doğrulama ile korunuyor
- ▢ ✅ Rate limit/throttle (HTTP ve queue) kurgulu
- ▢ ✅ Concurrency ve timeout limitleri tanımlı
- ▢ ✅ İdempotency ve retry stratejisi var
- ▢ ✅ Correlation id + audit log mevcut
- ▢ ✅ KVKK veri minimizasyonu ve log saklama politikası net
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Deliverables listesi
- •IAM policy seti (least privilege)
- •Secrets yönetim standardı + rotation
- •Event kontrol ve rate limit planı
- •Observability dashboard + audit log
- •Incident runbook
Bir Sonraki Adım
Fonksiyon bazlı IAM, secrets ve event kaynak risklerini netleştirip serverless mimaride güvenlik sınırlarını doğru çizen otel ve B2B ekipleri için.
Sık Sorulan Sorular
Serverless (FaaS) güvenliği nedir, klasik sunucudan farkı nedir?▾
AWS Lambda/Azure Functions gibi servislerde IAM ve secrets nasıl yönetilmeli?▾
Event tabanlı saldırılar serverless fonksiyonlarını nasıl etkiler?▾
Otel ve B2B için serverless nerede mantıklı, nerede riskli?▾
Lambda’ya attık, güvenlik cloud’un işi mi?▾
İlgili İçerikler