Entegrasyon anahtarları nerede saklanır, nasıl döndürülür

Entegrasyon anahtarları kaynak kodun içinde değil, ortam değişkenlerinde ya da bir sır kasasında saklanır ve her ortam için ayrı üretilir. Kod deposuna bir kez girmiş anahtar, depo özel olsa bile geçmiş kayıtlarda kalıcıdır; satırı silmek anahtarı geçersiz kılmaz, yalnızca görünmez yapar. Bu yazıda hangi bilgilerin sır sayıldığını, nerede saklanıp nerede saklanmayacağını, anahtarların kesintisiz nasıl değiştirileceğini ve sızıntı şüphesinde izlenecek sırayı anlatıyoruz.

Hangi bilgiler sır sayılır

• Dış servislerin API anahtarları ve erişim belirteçleri
• Uygulamanın veritabanı kullanıcı adı ve parolası
• E-posta gönderimi için kullanılan sunucu parolası
• İmzalama ve şifreleme için kullanılan özel anahtarlar
• Gelen webhook isteklerinin doğruluğunu kontrol eden imza anahtarı
• Yedekleme hedefine ve dosya depolamaya erişim bilgileri

Listeyi yazıya dökmek ilk adımdır. Çoğu ekip, kaç tane sırrı olduğunu ancak bu envanteri çıkardığında görür; sahipsiz kalmış eski bir anahtar neredeyse her kurulumda bulunur.

Nerede saklanmaz

Uygulamada en sık görülen yanlış yerler şunlardır: kaynak koda gömülü sabitler, sürüm kontrolüne eklenmiş yapılandırma dosyaları, yönetim panelinde düz metin gösterilen ayar alanları, e-posta ve mesajlaşma geçmişleri, proje notları ve ekran görüntüleri. Bir de kolay gözden kaçan yer var: hata ayıklama kayıtları. İstek gövdesini olduğu gibi günlüğe yazan bir entegrasyon, anahtarı günlük dosyasına ve oradan yedeklere taşır.

Aynı şekilde, geliştirme ve canlı ortamın aynı anahtarı paylaşması da bir saklama hatasıdır. Tek bir anahtar paylaşıldığında, ortamlardan birinde oluşan sızıntı hepsini birden etkiler.

Nerede saklanır

Hangi yöntem seçilirse seçilsin, iki şart ortaktır: değer ekranda bir daha tam olarak gösterilmez, yalnızca son birkaç karakteri görünür; ve anahtarı kimin ne zaman okuduğu kaydedilir.

Yöntem seçimi ölçekle birlikte değişir. Tek sunucuda çalışan bir kurulumda ortam değişkeni yeterliyken, sunucu sayısı arttıkça aynı sırrın elle birden fazla yere kopyalanması başlı başına bir arıza kaynağına dönüşür: değer bir yerde güncellenir, ötekinde eski kalır ve sorun en kötü zamanda ortaya çıkar. Dağıtım otomatikleştiği anda sırların tek bir kaynaktan okunması gerekir.

Her entegrasyona ayrı ve dar yetkili anahtar

Tek bir anahtarın bütün işleri görmesi kolaydır, ama sızıntı anında kaybı büyütür. Doğru yaklaşım, her entegrasyona kendi anahtarını vermek ve o anahtara yalnızca ihtiyacı olan yetkiyi tanımaktır. Kargo etiketi basan servisin müşteri listesini okumaya, rapor çeken servisin kayıt silmeye yetkisi olmamalıdır.

Ayrımın bir faydası daha var: hangi anahtarın ne kadar çağrı yaptığı ölçülebilir hâle gelir. Beklenmedik bir artış ya da alışılmadık bir saatte gelen çağrı, ancak anahtarlar ayrıştığında fark edilir. Uygulama içi rol ve yetki tasarımı ayrı bir konudur; buradaki yetki, sistemler arası erişimin sınırıdır.

Yetki daraltmanın pratik ölçütü tek bir sorudur: bu anahtar bugün dışarı çıksa en kötü ne olur? Cevap kabul edilemezse yetki hâlâ geniştir. Salt okunur bir anahtarla çalışabilecek bir rapor servisine yazma ve silme yetkisi vermek, hiçbir fayda sağlamadan bu cevabı ağırlaştırır.

Anahtar döndürme kesintisiz nasıl yapılır

1. Çift anahtar desteğini önce kurun. Uygulama aynı anda iki anahtarı da kabul edebilmeli; aksi hâlde her değişim kısa bir kesinti demektir.
2. Yeni anahtarı üretin ve yanına ekleyin. Eski anahtar hâlâ geçerliyken yeni anahtar devreye alınır.
3. Trafiği yeni anahtara taşıyın. Önce az kritik olan servisten başlanır, kayıtlardan yeni anahtarla gelen çağrılar izlenir.
4. Eski anahtarın kullanılmadığını doğrulayın. Belirli bir izleme penceresi boyunca eski anahtarla hiç çağrı gelmiyorsa geçiş tamamlanmıştır.
5. Eski anahtarı iptal edin ve kaydedin. İptal tarihi, gerekçe ve işlemi yapan kişi not edilir.

Döndürme işlemi yalnızca sızıntı şüphesinde değil, düzenli bir bakım işi olarak da planlanır. Ekipten biri ayrıldığında ve bir tedarikçi ilişkisi sona erdiğinde döndürme kaçınılmazdır.

Sızıntı şüphesinde izlenecek sıra

Şüphe anında tartışmak için zaman harcanmaz, sıra izlenir. Önce ilgili anahtar iptal edilir; kaybedilen işlev, iptal edilmeyen anahtarın yaratacağı zarardan ucuzdur. Ardından o anahtarla yapılan çağrıların kayıtları geriye dönük taranır ve olağan dışı işlem olup olmadığı çıkarılır. Sonra yeni anahtar üretilip dağıtılır, anahtarın nereye sızdığı tespit edilir ve aynı yoldan başka sırların da gitmiş olabileceği kontrol edilir. Son adım, sızıntıya yol açan alışkanlığın düzeltilmesidir: günlüğe yazılan istek gövdesi, paylaşılan bir dosya ya da ortak kullanılan bir hesap.

Bu sıranın olaydan önce yazılı olması belirleyicidir. İptal yetkisinin kimde olduğu, yeni anahtarın nereden üretileceği ve hangi servislerin etkileneceği o anda araştırılırsa kesinti uzar. Etkilenecek servislerin listesi sır envanterinin yanında, güncel hâliyle tutulur.

Kısa kontrol listesi

• Kullanılan bütün sırların yazılı bir envanteri var mı?
• Kod deposunda geçmişe kalmış anahtar araması yapıldı mı?
• Her ortam kendi anahtar setini mi kullanıyor?
• Her entegrasyonun ayrı ve dar yetkili bir anahtarı var mı?
• Uygulama aynı anda iki anahtarı kabul edebiliyor mu?
• Günlük kayıtlarına anahtar ve belirteç yazılması engellendi mi?

KAV Yazılım, entegrasyon projelerinde anahtar yönetimini kurulum belgesine bağlar; sırların nerede durduğu bilinmeyen bir sistem devredilemez de.