Startup'lar İçin Minimum Güvenlik Kontrol Listesi

Küçük bir ekipte hızlı ilerlemek ile güvenliği doğru uygulamak arasındaki denge, çoğu startup için gerçek bir gerilim noktasıdır. “Büyüyünce hallederiz” mantığıyla ertelenen güvenlik kararları, ilerleyen dönemde ciddi teknik borç ve operasyonel risk yaratır. Oysa temel güvenlik önlemlerinin büyük çoğunluğu ne pahalıdır ne de aylarca sürer.

Bu yazı, teknik ekiplerin kısa sürede hayata geçirebileceği, kanıtlanmış minimum güvenlik önlemlerini ele alıyor. Teori değil, pratik.

---

1. Secret ve Credential Yönetimi

Güvenlik ihlallerinin önemli bir kısmı, kaynak koduna veya konfigürasyon dosyalarına gömülü API anahtarlarından, veritabanı şifrelerinden ya da token’lardan kaynaklanır. Bu hata, düzeltmesi en zor görünen ama önlemesi en kolay olan hatadır.

Yapılacaklar:

• API anahtarları, veritabanı bağlantı bilgileri ve şifreler hiçbir zaman kaynak koduna yazılmaz. Geliştirme ortamında .env dosyası, üretimde bir secrets manager kullanılır.
• AWS Secrets Manager, HashiCorp Vault, Doppler veya benzer araçlar küçük ekipler için bile makul maliyetlidir.
• .env dosyaları .gitignore listesinde mutlaka yer alır. Repoya girmemesi gereken dosya tipleri için .gitignore şablonları kullanılır.
• Eski ve kullanılmayan API anahtarları düzenli aralıklarla iptal edilir.
• git-secrets veya truffleHog gibi araçlarla CI/CD pipeline’ına secret tarama adımı eklenir.

Kontrol: Repoda herhangi bir grep -r "password\|secret\|api_key" araması yapıldığında ne çıkıyor?

---

2. Erişim Kontrolü ve En Az Yetki İlkesi

Her kullanıcı ve her servis, yalnızca ihtiyacı olan izinlere sahip olmalıdır. Bu, hem dahili sistemler hem de bulut altyapısı için geçerlidir.

Yapılacaklar:

• Veritabanı kullanıcıları uygulama ihtiyacına göre sınırlı yetkiyle oluşturulur. Uygulamanın veritabanında DROP TABLE yapması gerekmiyorsa bu yetkiye sahip olmamalıdır.
• IAM rolleri ve politikaları bulut platformlarında (AWS, GCP, Azure) prensip olarak “minimum yetki” anlayışıyla yapılandırılır.
• Yönetici panelleri ve kritik endpoint’ler IP kısıtlaması veya ek doğrulama katmanıyla korunur.
• Çalışan ayrılmalarında erişim iptali süreci net ve hızlı işlemelidir.
• Tüm kritik sistemlerde çok faktörlü doğrulama (MFA) zorunlu tutulur.

---

3. Bağımlılık Güvenlik Taraması

Uygulamanızda kullandığınız açık kaynak kütüphaneler, bilinen güvenlik açıkları içeriyor olabilir. Bu açıkları takip etmek artık otomatize edilebilir bir iş.

Yapılacaklar:

• npm audit, pip-audit, bundler-audit gibi araçlar CI pipeline’ına entegre edilir.
• GitHub Dependabot veya Snyk gibi servisler ile otomatik güvenlik bildirimleri aktif tutulur.
• Kritik ve yüksek seviyeli güvenlik açıkları belirlenen süre içinde (örneğin 7 gün) kapatılmalıdır.
• Kullanılmayan bağımlılıklar düzenli olarak temizlenir; saldırı yüzeyi küçültülür.

---

4. HTTPS ve Aktarımdaki Veri Güvenliği

2026’da hâlâ HTTP üzerinden çalışan bir uygulama, temel bir güvenlik koşulunu karşılamıyor demektir.

Yapılacaklar:

• Tüm trafik HTTPS üzerinden yönlendirilir; HTTP’den HTTPS’e otomatik yönlendirme yapılır.
• TLS 1.2 minimum versiyon olarak kabul edilir; TLS 1.3 tercih edilir.
• HSTS (HTTP Strict Transport Security) başlığı aktif edilir.
• API’lerde hassas veriler response body’de gerektiği kadar paylaşılır, header’lar gereksiz bilgi içermez.

---

5. Kimlik Doğrulama ve Oturum Yönetimi

Zayıf kimlik doğrulama mekanizmaları, en yaygın saldırı vektörlerinden biridir.

Yapılacaklar:

• JWT kullanıyorsanız: token süresi kısa tutulur (access token için 15 dakika ile 1 saat arası), refresh token’lar güvenli şekilde saklanır ve sunucu tarafında iptal mekanizması bulunur.
• Parola politikası belirlenmiş olmalıdır: minimum uzunluk, sözlük saldırılarına karşı koruma.
• Bcrypt, Argon2 veya benzer algoritmalar parolalar için kullanılır. MD5 ve SHA-1 parola hash’lemede kabul edilmez.
• Brute-force saldırılarına karşı rate limiting ve hesap kilitleme mekanizması uygulanır.
• “Şifremi unuttum” akışı güvenli token tabanlı çalışır; e-posta adresi doğrulama ile tamamlanır.

---

6. Loglama ve Denetim İzleri

Ne zaman, kim, neye erişti? Bu sorunun yanıtı olmadan güvenlik olaylarını tespit etmek ve müdahale etmek neredeyse imkansızdır.

Yapılacaklar:

• Kimlik doğrulama olayları (başarılı giriş, başarısız giriş, parola değişikliği) loglanır.
• Kritik veri erişimleri ve değişiklikler denetim loğuna yazılır.
• Log dosyaları merkezi bir sistemde toplanır (ELK, Datadog, Grafana Loki, vb.).
• Log’lara kişisel veri veya credential yazılmaz; log’lar veri sızıntısı kaynağına dönüşmemelidir.
• Anormal aktivite için temel alarm kuralları oluşturulur.

---

7. Güvenlik Uzmanını Ne Zaman Dahil Etmeli?

Yukarıdaki önlemler bir başlangıç noktasıdır. Aşağıdaki durumlarda bir güvenlik uzmanıyla çalışmayı değerlendirmeniz gerekir:

• Ödeme verisi (PCI-DSS kapsamı) veya sağlık verisi işliyorsanız
• Seri A veya sonrası yatırım turuna hazırlanıyorsanız (yatırımcılar güvenlik due diligence yapıyor)
• KVKK veya GDPR kapsamında kişisel veri işliyorsanız
• Kurumsal müşterilere satış yapıyorsanız ve güvenlik sorguları alıyorsanız
• Bir güvenlik olayı yaşadıysanız veya şüpheleniyorsanız

---

Hızlı Kontrol Listesi

[ ] API anahtarları ve şifreler kaynak kodunda yok
[ ] .env dosyası .gitignore'da
[ ] Production'da secrets manager kullanılıyor
[ ] MFA kritik sistemlerde zorunlu
[ ] CI'da bağımlılık güvenlik taraması var
[ ] Tüm trafik HTTPS üzerinden
[ ] JWT süresi makul şekilde kısa
[ ] Brute-force koruması aktif
[ ] Kimlik doğrulama olayları loglanıyor
[ ] Ayrılan çalışanların erişimi hemen kaldırılıyor

---

Güvenlik, büyük bütçe veya büyük ekip gerektirmiyor. Gerektirdiği şey sistematik düşünce ve tutarlı uygulama. Bu listedeki her madde, bir güvenlik açığının önüne geçmek için yapılmış pratik bir yatırımdır.

Ekibinizin güvenlik olgunluğunu değerlendirmek veya yatırım öncesi güvenlik hazırlığı hakkında konuşmak isterseniz, ücretsiz bir keşif görüşmesi için bize ulaşabilirsiniz.