Gizli anahtarları koddan çıkarmak: yönetim ve döndürme

Altay Kargo'da bir geliştirici, ödeme entegrasyonunu hızlıca denemek için API anahtarını ayar dosyasına yazar. Yirmi dakika sonra anahtarı ortam değişkenine taşır ve yeni bir commit atar.

Dosya artık temiz görünür. Oysa anahtar hâlâ depodadır, üstelik her klonda ve her yedekte durur. Bu ders o yirmi dakikanın izini sürer.

Önce hangi sırlara sahip olduğunu çıkarır, gömülü sırrı git geçmişinde bulursun. Sonra sırrı çalışma zamanında bir gizli anahtar yöneticisinden alırsın. Ardından taramayla erken yakalar, sızıntıya doğru sırayla müdahale eder ve döndürmeyi otomatiğe bağlarsın.

Sır (secret), bir sisteme erişim ya da imza yetkisi veren her değerdir. API anahtarı, veritabanı parolası, JWT imza anahtarı, bulut erişim anahtarı, webhook imza sırrı ve SSH dağıtım anahtarı en yaygın örneklerdir. Her sır için dört soruyu yanıtlayan bir envanter tut. Sahibi kim?

Ömrü ne kadar? Nerede duruyor? Sızarsa nasıl iptal edilir? İptal yolunu önceden bilmek, olay anında dakikalar kazandırır.

Envanterde olmayan bir sırrı döndüremezsin. Altay Kargo'nun envanterinde ödeme anahtarının sahibi ödeme ekibidir. Anahtar 90 günde bir döner ve sağlayıcının panelinden tek tıkla iptal edilir.

Bir sırrı kaynak koduna yazmak ilk bakışta pratik görünür, ama kalıcı bir iz bırakır. Kod git deposuna gider ve git geçmişi kalıcıdır. Dosyadan silinen sır eski committe okunmaya devam eder. Aynı kod derleme kayıtlarına, konteyner katmanlarına, çatallanan (fork) kopyalara ve kod inceleme araçlarına da kopyalanır.

Sır bir kez koda girdiğinde onu görmüş her yeri saymak neredeyse imkânsızdır. Bu durum özel (private) depolar için de geçerlidir. Depoya erişmiş her eski çalışan ve her yedek, aynı sırrı görmüş olabilir. Sırrın izini bulmak için git'in kazma (pickaxe) aramasını kullanırsın.

$ git log -p -S 'sk_live_' --all
commit 811dc20cb47a95df8095a0d7e4c754d7912b2670
Author: Mert Kaya <[email protected]>
Date:   Sat Mar 14 17:05:31 2026 +0300

    Anahtarı ortam değişkenine taşı

-    API_ANAHTARI = "sk_live_9f3ac1b7d2e04af6c8b1"
+    API_ANAHTARI = os.environ["API_ANAHTARI"]

commit 7da2895d03bb63a0ace51b345f7205204094d890
Author: Mert Kaya <[email protected]>
Date:   Sat Mar 14 16:42:07 2026 +0300

    Ödeme entegrasyonu için hızlı test

+    API_ANAHTARI = "sk_live_9f3ac1b7d2e04af6c8b1"

Komutu parça parça oku. -S, verilen dizgenin geçme sayısını değiştiren commit'leri bulur. Yani sırrın eklendiği ve silindiği iki commit'i gösterir. --all yalnız bulunduğun dalı değil, bütün dalları tarar.

-p her commit'in farkını (diff) da basar. Çıktı yeni commit'ten eskiye doğru akar. Alttaki 7da2895 commit'i anahtarı ekler, üstteki 811dc20 onu siler. Silme commit'i sırrı yok etmez; git show 7da2895 komutu anahtarı bugün de gösterir.

Tarihler olay zaman çizelgesini verir. Anahtar 16.42'de depoya girdi. İptal edilene kadar geçen her dakika sızıntı penceresine eklenir.

Koda gömülü bir anahtarı değiştirmek yeni bir kod dağıtımı ister. Bu adım yavaş ve riskli görüldüğü için ertelenir, sır yıllarca aynı kalır. Doğru desen, sırrı koda hiç yazmamak ve çalışma zamanında almaktır. Kaynak bir ortam değişkeni ya da gizli anahtar yöneticisidir (secret manager).

Yerel geliştirmede kullanılan .env dosyası da git'e girmez, .gitignore listesinde durur. Yanlışlıkla commit edilen bir .env, koda gömülü sırla aynı sonucu doğurur. Üretimde değerleri dağıtım sistemi konteyner açılırken enjekte eder. Değer hiçbir noktada diske ya da imaja yazılmaz.

Gizli anahtar yöneticisi sırları merkezde saklar, erişimi yetkiye göre sınırlar ve her okumayı kaydeder. Vault, AWS Secrets Manager, GCP Secret Manager ve Azure Key Vault bilinen örneklerdir. Uygulama açılışta kendi kimliğiyle yöneticiye bağlanır ve ihtiyacı olan sırrı ister.

Değeri yalnız bellekte tutar, diske yazmaz. Burada bir tuzak var: uygulama yöneticiye statik bir parolayla bağlanırsa sorun bir kat yukarı taşınır. Buna ilk sır sorunu (secret zero) denir.

Çözüm, platformun verdiği kimliktir: bulutta IAM rolü, Kubernetes'te servis hesabı. Erişim kaydı hangi servisin hangi sırrı ne zaman okuduğunu gösterir. Sızıntıdan sonra etkilenen bileşeni bu kayıttan bulursun.

$ vault kv get -mount=secret jwt-imza-anahtari
======== Secret Path ========
secret/data/jwt-imza-anahtari

======= Metadata =======
Key                Value
---                -----
created_time       2026-09-01T08:12:44.918273Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            3

==== Data ====
Key      Value
---      -----
deger    oiMrE+T1zXD7uH0HW+RL/opz4ChvSJBRnp0E76zbizQ=

$ vault kv get -mount=secret -field=deger jwt-imza-anahtari
oiMrE+T1zXD7uH0HW+RL/opz4ChvSJBRnp0E76zbizQ=

$ aws secretsmanager get-secret-value --secret-id jwt-imza-anahtari --query SecretString --output text
oiMrE+T1zXD7uH0HW+RL/opz4ChvSJBRnp0E76zbizQ=

Çıktıyı bölüm bölüm oku. Secret Path, KV motorunun 2. sürümünde sırrın gerçek yolunu gösterir; araya data eklenir. Metadata bölümünde version 3 yazar.

Sır iki kez döndürülmüştür ve eski sürümler geri okunabilir. Data bölümü değerin kendisidir. -field=deger yalnız değeri basar, betikte kullanmak için budur.

AWS komutunda --query SecretString yanıttan yalnız sırrı seçer, --output text de onu tırnaksız yazar. İki araç da değeri terminale açık yazar. Bu komutları ekran paylaşımında ya da günlüğü tutulan bir CI adımında çalıştırma.

Uygulama aynı değeri kendi SDK'sıyla okur ve yalnız bellekte tutar. -mount bayrağı Vault'un kendi yardım metninin önerdiği yazımdır. Eski secret/jwt-imza-anahtari yazımı da çalışır ve araya data'yı kendisi ekler.

Sızıntıyı en ucuz yakaladığın yer, geliştiricinin kendi makinesidir. Tarama üç noktaya konur. Birincisi commit öncesi kancadır (pre-commit hook); sır daha commit'e girmeden yakalanır.

İkincisi CI'dır; her push'ta bütün değişiklik taranır. Üçüncüsü, depo geçmişinin tamamı üzerinde bir kerelik taramadır. gitleaks bu iş için yaygın bir açık kaynak araçtır.

Kurallarını düzenli ifade ve rastgelelik ölçüsü (entropi) üzerine kurar. Depo barındırma tarafında da bir katman vardır. GitHub'ın kullanıcı düzeyindeki push koruması, genel depolara sır gönderimini varsayılan olarak durdurur. Kullanıcı bu engeli aşabilir, bu yüzden tek katman olarak yetmez.

$ gitleaks git -v .
Finding:     API_ANAHTARI = "sk_live_9f3ac1b7d2e04af6c8b1"
Secret:      sk_live_9f3ac1b7d2e04af6c8b1
RuleID:      stripe-access-token
Entropy:     4.307355
File:        config/ayarlar.py
Line:        5
Commit:      7da2895d03bb63a0ace51b345f7205204094d890
Author:      Mert Kaya
Email:       [email protected]
Date:        2026-03-14T13:42:07Z
Fingerprint: 7da2895d03bb63a0ace51b345f7205204094d890:config/ayarlar.py:stripe-access-token:5

INF 3 commits scanned.
WRN leaks found: 1

$ gitleaks dir -v .
INF no leaks found

Bulguyu alan alan oku. Finding, sırrın geçtiği satırdır. Secret yalnız yakalanan değeri gösterir. RuleID hangi kuralın tetiklendiğini söyler; sk_live_ öneki bir ödeme sağlayıcısının anahtar biçimidir.

Entropy, dizgenin ne kadar rastgele göründüğünü ölçer. Rastgele anahtarlar yüksek, sıradan kelimeler düşük değer alır. File ve Line yeri, Commit, Author ve Date zamanı verir. Fingerprint, bulgunun benzersiz kimliğidir.

Asıl ders son komuttadır. gitleaks dir yalnız çalışma dizinini tarar ve temiz der, çünkü dosya bugün temizdir. gitleaks git ise geçmişi tarar ve sızıntıyı bulur. Bulgu olursa araç 1 çıkış koduyla döner ve CI adımı düşer.

Her bulgu gerçek sızıntı değildir. Önce dosyaya bak: üretim yapılandırması mı, test ya da belge mi? Sonra değere bak: yüksek entropili bir anahtar mı, BURAYA_YAZ gibi bir yer tutucu mu? Özel anahtar kuralı neredeyse her zaman gerçektir.

Emin değilsen sağlayıcıda anahtarın etkin olup olmadığına bak. Yanlış pozitifi inceledikten sonra iki yolla susturursun. Parmak izini depo kökündeki .gitleaksignore dosyasına eklersin ya da satıra gitleaks:allow yorumu koyarsın.

Depoda durması gereken yapılandırma varsa SOPS kullan. SOPS dosyadaki değerleri şifreler, anahtar adlarını açık bırakır. Böylece farklar okunur, sır okunmaz.

Genel bir depoya giden sır için saat dakikalarla işler. Otomatik tarayıcılar yayımlanan commit'leri sürekli izler ve sır kalıbına benzeyen dizgeleri toplar. Doğru müdahale dört adımdır ve sırası değişmez. Birincisi sırrı sağlayıcıda iptal etmek ve yenisini üretmektir.

Yeni sır yöneticiye girer, servisler onu okur. İkincisi kapsamı belirlemektir. Sağlayıcının erişim günlüğünde sızıntı penceresine bakarsın: commit anından iptal anına kadar anahtarı kim, nereden kullandı? Üçüncüsü geçmişi temizlemektir.

Dördüncüsü önlemdir: tarama kancası, push koruması ve olay kaydı. Sıra önemlidir, çünkü geçmiş temizliği klonlara ve çatallara ulaşmaz. İptal ise sırrı her yerde bir anda değersiz kılar.

$ git-filter-repo --sensitive-data-removal --invert-paths --path config/uretim.env
$ git push --force --mirror origin

Komutları sırayla oku. --sensitive-data-removal bayrağı için git-filter-repo'nun en az 2.47 sürümü gerekir; sürümünü önce denetle. --invert-paths ile --path birlikte, verilen dosyayı bütün commit'lerden çıkarır. Geriye kalan commit'lerin kimlikleri değişir.

Zorla ayna itme (push --force --mirror) sunucudaki dalları yeniden yazar. Ekipteki herkes kendi dalını yeni geçmişin üstüne taşır (rebase), birleştirme (merge) yapmaz. Eski geçmişi taşıyan tek bir merge commit'i sırrı geri getirebilir. GitHub belgeleri iki uyarı daha yapar.

Çatallardaki kopyalar senin kontrolünde değildir. Önbelleğe alınmış görünümler ve açık çekme istekleri için destek ekibine başvurman gerekir. Bu yüzden temizlik, iptalin yerini tutmaz.

Döndürme (rotation), sızıntı olmasa bile sırrın düzenli aralıklarla yenilenmesidir. Elle yapılan döndürme ertelenir ve unutulur, bu yüzden takvime ve otomasyona bağlanır. Kesintisiz döndürmede yeni anahtar yöneticiye girer.

Kısa bir geçiş penceresinde iki anahtar da geçerlidir. Bütün servisler yenisine geçince eskisi iptal edilir. Kısa ömürlü kimlik bilgisi bu ihtiyacı büyük ölçüde kaldırır, çünkü kendiliğinden geçersiz olur.

CI/CD boru hattı bu ilkenin en çok işe yaradığı yerdir. Ayarlara konmuş uzun ömürlü bir bulut anahtarı saldırganın birinci hedefidir. OIDC federasyonu bu anahtarı kaldırır. İş akışı çalışırken CI platformundan kısa ömürlü, imzalı bir kimlik jetonu ister.

Bulut tarafındaki rol, jetonun hangi depodan ve daldan geldiğini denetler. Koşul tutarsa yalnız o iş için geçici anahtar verir. Depoda ya da CI ayarlarında çalınacak statik sır kalmaz.

permissions:
  id-token: write      # OIDC jetonu istemek için
  contents: read
steps:
  - uses: aws-actions/configure-aws-credentials@v6
    with:
      role-to-assume: arn:aws:iam::111122223333:role/altaykargo-dagitim
      aws-region: eu-central-1

Satırları oku. id-token: write, iş akışının OIDC jetonu istemesine olanak verir. Bu izin olmadan jeton alınamaz. contents: read, depoya yalnız okuma yetkisi bırakır.

configure-aws-credentials adımı jetonu bulut sağlayıcıya götürür ve role-to-assume ile verilen rolü üstlenir. Rolün güven politikası jetonun yayıncısını, yani token.actions.githubusercontent.com adresini tanır. Jetondaki sub alanında depo ve dal adı yazar. Politika bu alanı yalnız ana dal için kabul ederse, başka bir daldan ya da çekme isteğinden çalışan iş rolü üstlenemez.

Son olarak sık hataları topla. Sırrı günlüğe yazmak (CWE-532) onu günlüğü okuyan herkese dağıtır; hata ayıklama satırları en sık kaynaktır. Dockerfile içinde ENV ya da ARG ile verilen sır son imajda kalır. Docker belgeleri bunun yerine derleme sırrı bağlamayı (RUN --mount=type=secret) önerir.

Ön yüz paketine giren değerler de sır değildir. NEXT_PUBLIC_ ya da VITE_ önekli değişkenler tarayıcıya giden JavaScript'e gömülür. CI'da maskeleme de tek başına yetmez.

Maskeleme yalnız bilinen değerleri gizler; farklı kodlanmış ya da parça parça yazdırılan bir değer maskeden kaçar. Asıl kural, sırrı hiç yazdırmamaktır.