Küçük ekiplerde secret ve erişim: şifreyi chat'e yapıştırmadan

Secret yönetimi bir vault ürünü kataloğu değil; kim hangi anahtara nasıl ulaşıyor, nereye yazılmıyor ve bir sızıntıda ne yapılacağı sorusuna verilen yazılı cevaptır. Bu yazıda 3–20 kişilik ekipler için abartısız bir düzen öneriyoruz: chat ve repo dışında tut, ortamları ayır, erişimi kişiden role bağla, döndürmeyi unutma.

Küçük ekiplerde secret'lar çoğu zaman "çalıştıran yerde" yaşar: .env dosyası birinin laptop'unda, Slack veya WhatsApp'ta bir API key, CI YAML'ına gömülü bir token, staging ile prod'un aynı şifreyi paylaşması.

TW Bilişim olarak yazılım ve DevOps işlerinde gördüğümüz tablo: sorun genelde "yeterince sofistike bir secret manager yok" değil; sızıntı yüzeyinin bilinmemesi ve kimsenin sahibi olmaması. Bir vault kurup hâlâ chat'e yapıştırmak mümkün.

Bu rehber, kendi ürününü veya müşteri yazılımını işleten ekipler içindir. Araç adları örnek (GitHub Actions secrets, bulut secret manager, password manager); önemli olan düzen. Blog serisindeki diğer operasyon yazılarıyla aynı çizgide ilerliyoruz.

Önce envanter — ne secret sayılır?

Pipeline veya vault seçmeden önce kısa bir liste yeter:

1. Kimlik: veritabanı şifresi, admin paneli, SSH / deploy anahtarı
2. Entegrasyon: ödeme, e-posta, SMS, harita, AI API key'leri
3. İmzalar: JWT secret, webhook HMAC, sertifika private key
4. Altyapı: bulut access key, registry token, DNS API

"Bu değer log'a düşse veya repo'ya commit'lense zarar eder mi?" sorusuna evet ise secret'tır. Müşteri verisi veya PII ayrı bir sınıf; bu yazı anahtar ve kimlik bilgisine odaklanır.

Üç yerde asla

Küçük ekiplerde en sık sızıntı yolları:

• Sohbet ve e-posta: "bir kez atayım" kalıcı arşiv demektir
• Git geçmişi: .env bir kez push edildiyse silmek yetmez; geçmişte durur
• Uygulama / CI log'u: debug için env dump, hata mesajında connection string

Pratik kural: secret'ı taşımak için sohbet yerine password manager paylaşımı veya kısa ömürlü, tek kullanımlık kanal. Repo'da yalnız örnek dosya (.env.example) — gerçek değer yok.

Ortamları ayırın

Staging ile prod'un aynı veritabanı şifresini veya aynı ödeme key'ini kullanması, "test ederken prod'u yaktık" senaryosunun klasik yoludur.

Minimum ayrım:

Ortam	Secret seti	Kim yazar / döndürür
Yerel geliştirme	Kişisel veya paylaşılan dev seti	Geliştirici; prod anahtarı yok
Staging	Staging-only key'ler	Deploy hattı + 1–2 kişi
Prod	Prod-only; mümkünse kısıtlı scope	En dar grup + audit

Test ödeme / sandbox key varsa onu staging'de kullanın; "canlı key ile staging" çoğu ekipte erken bir alışkanlıktır ve pahalıya patlar.

CI/CD: secret store, gömülü string değil

Önceki CI/CD yazısındaki gibi: pipeline'a gömülü şifre kısa vadede işe yarar, uzun vadede sızıntı ve rotation engeli olur.

Pratik:

• Secret'lar CI/CD secret store veya bulut secret manager'da
• Job log'larında maskeleme açık olsun; echo $SECRET ile debug yasak
• Fork PR'larından secret'lara erişim kapalı (veya bilinçli istisna)
• Deploy anahtarı mümkünse salt-okunur veya tek repo'ya scoped

"Hangi commit hangi secret'ı kullandı?" sorusu genelde log'da cevaplanmamalı; secret değeri değil, hangi ortamın deploy edildiği görünür olmalı.

İnsan erişimi: kişi değil rol

Tek kurucu her panoda admin ise, o kişi tatildeyken veya ayrılırken her kapı kilitli kalır — ya da herkes aynı master şifreyi bilir.

Sade model:

• Rol: "prod deploy", "fatura paneli", "DNS" — isimlere değil rollere bağlayın
• En az yetki: günlük iş için admin gerekmiyorsa admin vermeyin
• Paylaşılan hesap yerine bireysel hesap + grup / SSO (mümkünse)
• Ayrılma checklist'i: bir paragraf yeter — hangi sistemlerden erişim kesilir?

Password manager (1Password, Bitwarden, benzeri) ekip vault'u, "şifreyi birine sor" yerine tek kaynak olur. Chat'e yapıştırma ihtiyacı çoğu zaman vault yokluğundan doğar.

Gözlemlenebilirlik yazımızdaki gibi: sahipsiz bir erişim paneli, sahipsiz bir alarm gibidir — bir süre yeşil görünür, sorunca kim neye girebiliyor kimse anlatamaz.

Rotation ve sızıntı anı

Rotation'ı yılda bir "büyük proje" yapmayın; en azından şunu bilin:

• Hangi secret'lar kritik (ödeme, prod DB, root cloud)?
• Birini değiştirince hangi servisler yeniden deploy / config ister?
• Sızıntı şüphesinde ilk 30 dakika: hangi key iptal, hangi oturumlar düşürülür?

Abartılı prosedür şart değil. Bir sayfalık "sızıntı notu" + kritik key'lerin kim tarafından döndürülebileceği çoğu 3–20 kişilik ekip için yeterlidir. Yedekleme yazısındaki gibi: planın değeri denendiğinde ortaya çıkar — bir kez staging'de key rotate denemek, dokümanın yarısıdır.

Uygulama tarafı: kodda secret yok

Geliştirici alışkanlıkları:

• Config'te secret'ı environment / secret manager'dan oku; kaynağa yazma
• Client (tarayıcı / mobil) tarafına yalnız public anahtarlar; private key asla
• Webhook imza doğrulama; "gizli URL yeter" varsayımına güvenme
• Hata sayfalarında ve destek ekran görüntülerinde connection string / token maskele

Framework'lerin "secret'ı .env'den okur" modeli iyidir; .env'nin commit'lenmesi ve prod sunucuda dünya-okunur kalması ayrı risklerdir.

Pratik checklist

Madde	Net mi?	Not
Secret envanteri (kısa liste)	☐	En az kritikler
Chat / e-posta ile key yasak (alternatif kanal var)	☐	Password manager
Repo'da yalnız .env.example	☐	Geçmiş tarandı
Staging ≠ prod secret	☐	Ödeme sandbox
CI secret store kullanımı	☐	Log maskeli
Rol bazlı erişim + ayrılma notu	☐	Bir paragraf
Kritik key için rotation / sızıntı notu	☐	Sahip belli
Client'a private key yok	☐	Review'da bakılır

SSS

Her secret için kurumsal vault şart mı?
Hayır. Küçük ekipte sağlam bir password manager + CI secret store + ortam ayrımı çoğu zaman ilk adım olarak yeter. Vault, süreç yoksa tek başına kurtarmaz.

.env dosyası güvensiz mi?
Yerelde ve sunucuda doğru izinlerle kullanmak yaygın ve kabul edilebilir. Risk: commit, sohbet kopyası, paylaşılan ekran görüntüsü ve staging/prod karışımı.

API key'i URL'de query string olarak vermek olur mu?
Mümkün olduğunca hayır — log, proxy ve Referer ile sızar. Header veya sunucu tarafı imza tercih edin.

Eski çalışan hâlâ erişiyor olabilir mi?
E-posta ve "şu panele bak" ile açılmış hesaplar checklist olmadan unutulur. Ayrılma notunu bir kez yazmak, sonradan panik aramaktan ucuzdur.

TW Bilişim bu konuda ne yapıyor?
Mevcut repo, host ve entegrasyonlara uygun, abartısız secret ve erişim düzeni kuruyoruz: nerede duruyor, kim erişiyor, CI nasıl okuyor, sızıntıda ne yapılacağı. Amaç vitrin bir güvenlik programı değil; ekibinizin gerçekten uyguladığı birkaç kural bırakmak.

Sonuç

Sırayı basit tutun: ne secret → sohbet ve git dışında tut → ortamları ayır → CI ve insan erişimini daralt → rotation / sızıntı notu yaz. Bu sıra netse araç seçimi ikincil kalır.

Secret ve erişim düzeninizi birlikte sadeleştirmek isterseniz: iletişim veya [email protected].