Güvenlik konuşmaları genellikle insan kullanıcıların parolalarına ve doğrulama yöntemlerine odaklanır. Oysa modern bir acente yazılımında isteklerin önemli bir kısmı insanlar tarafından değil, sistemler tarafından yapılır. Teklif motorunun sigorta şirketi servislerine bağlanması, web sitesindeki formun panele talep aktarması, muhasebe aracına veri gönderilmesi ya da gece çalışan bir raporlama görevinin veritabanına erişmesi, hep bir makine kimliği üzerinden gerçekleşir.
Bu makine kimlikleri, yani servis hesapları ve API anahtarları, çoğu zaman bir kez oluşturulup unutulur. Unutulan bir anahtar ise yıllar boyunca geçerliliğini koruyan, kimin elinde olduğu bilinmeyen bir erişim yetkisine dönüşür. Bu yazıda makine kimliklerinin yaşam döngüsünü dört aşamada inceliyoruz.
Makine kimliği neden ayrı ele alınmalı?
İnsan hesaplarında çok faktörlü doğrulama, oturum süresi ve cihaz tanıma gibi koruma katmanları bulunur. Bir API anahtarında ise bunların çoğu yoktur: Anahtarı bilen, anahtarın yetkisine sahiptir. Bu nedenle makine kimlikleri için koruma, anahtarın kendisinin nasıl yönetildiğine bağlıdır.
Ayrıca makine hesaplarının sahipliği belirsiz kalmaya eğilimlidir. Entegrasyonu kuran kişi ayrıldığında anahtarın ne işe yaradığını, hangi sistemlerde kullanıldığını ve iptal edilirse neyin bozulacağını bilen kimse kalmayabilir.
Aşama 1: Oluşturma
Güvenli bir yaşam döngüsü, anahtar daha oluşturulurken başlar.
- Her entegrasyon için ayrı kimlik: Web sitesi formu, muhasebe aktarımı ve raporlama görevi aynı anahtarı paylaşmamalıdır. Ayrı kimlikler, bir sorunda yalnızca ilgili bağlantıyı kapatmayı mümkün kılar.
- Dar kapsam: Yalnızca talep oluşturması gereken bir form entegrasyonu, müşteri listesini okuyabilmemelidir.
- Sahip ataması: Her anahtarın kayıtlı bir sorumlusu, açıklaması ve oluşturulma tarihi olmalıdır.
- Son kullanma tarihi: Mümkün olduğunda anahtarlar süresiz değil, belirli bir süre sonra geçersiz olacak şekilde üretilmelidir.
Aşama 2: Saklama
Anahtarların en sık sızdığı yerler beklenmedik kadar sıradandır: kaynak kod deposuna yanlışlıkla eklenen yapılandırma dosyaları, ekip içi mesajlaşma kanallarında paylaşılan ekran görüntüleri, e-posta ile gönderilen kurulum notları.
Güvenli saklama için temel kurallar şunlardır:
- Anahtarlar kaynak koda gömülmez; çalışma ortamına güvenli bir yapılandırma mekanizmasıyla verilir.
- Paylaşım gerekiyorsa mesajlaşma uygulaması yerine erişim kontrollü bir gizli bilgi kasası kullanılır.
- Kasaya kimin, ne zaman eriştiği kayıt altına alınır.
- Geliştirme, test ve canlı ortamlar için farklı anahtarlar kullanılır; test anahtarı canlı veriye erişemez.
Aşama 3: Döndürme
Anahtar döndürme, mevcut anahtarın yenisiyle değiştirilmesidir. Düzenli döndürme, bir anahtarın fark edilmeden sızmış olması ihtimaline karşı etkili bir güvencedir; sızan anahtarın geçerlilik süresi sınırlanmış olur.
Döndürmenin kesintisiz yapılabilmesi için sistemin aynı anda iki geçerli anahtarı kısa bir süre desteklemesi gerekir. Önerilen akış şöyledir:
- Yeni anahtar oluşturulur, eskisi henüz iptal edilmez.
- Entegrasyon yeni anahtarla çalışacak şekilde güncellenir.
- İşlem kayıtlarından eski anahtarla gelen istek kalmadığı doğrulanır.
- Eski anahtar iptal edilir.
Bu akış belgelenmediğinde döndürme işlemi "bir şey bozulur" korkusuyla sürekli ertelenir. Ertelenen döndürme ise anahtarın fiilen süresiz hale gelmesi demektir.
Aşama 4: İptal
Bir entegrasyon kullanımdan kalktığında, bir tedarikçiyle çalışma sona erdiğinde ya da bir anahtarın sızdığından şüphelenildiğinde iptal hızlı ve eksiksiz yapılabilmelidir. Bunun için:
- Tüm aktif anahtarların güncel bir envanteri bulunmalıdır.
- Her anahtarın hangi sistemlerde kullanıldığı bilinmelidir.
- İptal sonrası ilgili kimlikle gelen istekler reddedilmeli ve kayıt altına alınmalıdır.
Sigorta şirketi bağlantılarında özel durum
Bir teklif programı, trafik, kasko ve DASK sorgularını farklı sigorta şirketi servislerine ayrı akışlar halinde iletir. Her şirket bağlantısının kendi kimlik bilgisi ve yetki kapsamı vardır. Bu bağlantıların birbirinden izole tutulması, bir şirkete ait kimlik bilgisinde sorun yaşandığında diğer akışların etkilenmemesini sağlar. Aynı zamanda hangi isteğin hangi kimlikle yapıldığı ayrı ayrı izlenebilir.
Bir anahtarın sızdığından şüphelenildiğinde
Bir API anahtarının herkese açık bir depoda, paylaşılmış bir ekran görüntüsünde ya da yanlış kişiye gönderilmiş bir e-postada görüldüğü fark edildiğinde, "henüz kötüye kullanılmamıştır" varsayımıyla beklemek doğru değildir. Önerilen sıra şöyledir: Önce yeni bir anahtar üretilip entegrasyon ona geçirilir, ardından sızan anahtar iptal edilir. Sonrasında işlem kayıtları geriye dönük incelenerek sızan anahtarla beklenmeyen bir istek yapılıp yapılmadığı kontrol edilir. Son olarak sızıntının nasıl gerçekleştiği belirlenir ve aynı yolun tekrar kullanılmaması için süreç düzeltilir.
Yaygın hatalar
- Kişisel hesapla entegrasyon kurmak: Bir çalışanın kendi kullanıcı bilgileriyle kurulan entegrasyon, o kişi ayrıldığında ya da parolasını değiştirdiğinde beklenmedik biçimde bozulur.
- Yönetici yetkisiyle anahtar üretmek: "Nasılsa çalışsın" diye verilen geniş yetki, anahtar sızdığında hasarı büyütür.
- Anahtarı ortam değişkeni dökümlerinde açığa çıkarmak: Hata ayıklama sırasında alınan çıktılar ve log dosyaları anahtar içermemelidir.
- Envanteri yalnızca bir kişinin hafızasına bırakmak: Bilginin yazılı olmaması, iptal ve döndürme işlemlerini o kişiye bağımlı hale getirir.
Envanter için kısa bir şablon
Makine kimliklerinizi takip etmeye başlamak için her kayıtta şu bilgilerin bulunması yeterlidir:
- Kimliğin adı ve hangi entegrasyon için kullanıldığı
- Sorumlu kişi ve yedek sorumlu
- Yetki kapsamı (okuma, yazma, hangi modüller)
- Oluşturulma ve son döndürme tarihi
- Planlanan bir sonraki döndürme tarihi
Bu envanterin bir tablo olarak değil, erişim kontrollü bir kayıt olarak tutulması ve en az üç ayda bir gözden geçirilmesi önerilir. Gözden geçirmede kullanılmayan, sahibi belirsiz ya da döndürme tarihi geçmiş kimlikler ayrıca işaretlenir.
Makine kimliklerine insan kadar özen
Acentenizin güvenlik seviyesi, en az özen gösterilen kimlik kadar güçlüdür. Çalışan hesaplarına uygulanan disiplinin servis hesaplarına da taşınması, görünmeyen ama geniş yetkili erişim noktalarını kontrol altına alır. Entegrasyonlarınızın acente yazılımı içinde nasıl yönetildiğini görmek için demo talep formunu kullanabilirsiniz.