Yapay Zeka Modellerine Yönelik Prompt Injection Saldırıları Makalemiz Yayınlandı!
Siber Guvenlik Terimleri Sozlugu
Fail-secure arıza anında güvenliği, fail-safe ise can ve mal emniyetini önceleyen tasarım davranışıdır.

Her sistem bir gün beklenmedik bir durumla karşılaşır: bir bileşen yanıt vermez, bir bağlantı kopar, bir doğrulama servisi erişilemez hâle gelir. Bu anda sistemin nasıl davranacağı bir tasarım kararıdır ve önceden verilmelidir; verilmediğinde davranış rastgele olur.
Fail-secure ve fail-safe, bu kararın iki yönünü tanımlar. Birincisi arıza anında güvenliği korumayı, ikincisi ise insan ve varlık emniyetini korumayı önceler. İkisi çoğu zaman birbiriyle çelişir ve doğru seçim bağlama bağlıdır.
Fail-secure, bir arıza durumunda sistemin erişimi kapatarak güvenli tarafta kalmasıdır. Fail-safe ise arıza durumunda sistemin can ve mal emniyetini önceleyerek, gerekirse erişimi serbest bırakmasıdır.
Klasik örnek elektronik kapı kilitleridir. Elektrik kesildiğinde kilitli kalan bir kapı fail-secure davranır: içeri izinsiz giriş engellenir ama içerideki insanlar mahsur kalabilir. Kesinti anında açılan bir kapı ise fail-safe davranır: tahliye mümkün olur ama fiziksel güvenlik ortadan kalkar.
Yazılım tarafında en sık karşılaşılan durum, yetkilendirme servisinin yanıt vermemesidir. Fail-secure tasarımda istek reddedilir; kullanıcı erişemez ama yetkisiz erişim de olmaz. Fail-open denilen karşıt davranışta ise istek geçirilir ve doğrulama yapılmadan erişim verilir.
Fail-open davranışı çoğunlukla kasıtlı bir tercih değil, bir ihmalin sonucudur. Kod içinde hata yakalanır, kayıt yazılır ve akış devam eder; sonuçta doğrulama başarısız olduğu hâlde işlem tamamlanır. Bu kalıp, sızma testlerinde sıkça karşılaşılan ciddi bulgulardan biridir.
Sızma testinden olay müdahalesine, uçtan uca çözümlerle yanınızdayız.
Fiyat Teklifi AlSeçim, arızanın yol açacağı iki farklı zararın karşılaştırılmasıyla yapılır. Erişimin kesilmesi can güvenliğini tehlikeye atıyorsa fail-safe, yetkisiz erişim daha büyük zarar üretiyorsa fail-secure tercih edilir.
Yangın çıkışı kapıları, tıbbi cihazlar ve endüstriyel emniyet sistemleri fail-safe tarafında konumlanır. Veri merkezi kabinleri, kimlik doğrulama akışları ve finansal işlem onayları ise fail-secure tarafındadır. Aynı kurumda her iki davranışın farklı sistemlerde bulunması olağandır.
Karar, tasarım belgesinde açık biçimde yazılır: hangi bileşen arızalandığında sistemin ne yapacağı, hangi gerekçeyle bu davranışın seçildiği ve hangi telafi edici kontrolün devrede olacağı belirtilir. Yazılmayan karar, sonraki bakım çalışmalarında farkında olmadan değiştirilir.
Endüstriyel ortamlarda emniyet, güvenliğin önünde gelir. Bir üretim hattında güvenlik kontrolünün devreye girmesi süreci tehlikeli bir duruma sokuyorsa, o kontrol o hâliyle uygulanamaz. Bu ortamlarda tasarım, emniyet mühendisleriyle birlikte yapılır.
Çözüm çoğunlukla ayrıştırmadır: güvenlik kontrolleri emniyet fonksiyonunun üzerinde değil, yanında konumlandırılır. Emniyet sistemleri kendi ayrık ağında ve kendi mantığıyla çalışırken, güvenlik izlemesi pasif biçimde yürütülür.
Bu ayrımın kaydı da tutulur. Hangi kontrolün hangi emniyet gerekçesiyle uygulanmadığı yazıldığında, bu bilinçli bir artık risk kabulü olur; yazılmadığında ise bir kontrol boşluğu olarak kalır.
Ağ üzerinde satır arası çalışan güvenlik ürünleri özel bir dikkat gerektirir. Bir güvenlik duvarı ya da içerik denetim cihazı arızalandığında trafiği geçirmeye devam ediyorsa, ortamın güvenliği sessizce ortadan kalkmış olur.
Birçok üründe bu davranış yapılandırılabilir. Karar verilirken kesinti maliyeti ile denetimsiz trafiğin riski karşılaştırılır; kritik ortamlarda genellikle trafiğin durdurulması, yedekli cihaz mimarisiyle birlikte tercih edilir.
Yedeklilik burada belirleyicidir. Fail-secure davranış yalnızca yedekli bir mimariyle birlikte sürdürülebilir; tek cihaza dayanan bir tasarımda katı davranış, sık kesinti nedeniyle zamanla gevşetilir.
Arıza davranışı yalnızca gerçekten arıza üretilerek doğrulanabilir. Belgede fail-secure yazması, sistemin sahada öyle davranacağını göstermez; bağımlılıklardan biri beklenmeyen bir yol izleyerek isteği geçirebilir.
Bu nedenle bileşenlerin bilinçli olarak devre dışı bırakıldığı testler planlanır: kimlik sağlayıcısı erişilemez yapılır, kayıt hedefi kapatılır, politika sunucusuna giden yol kesilir ve sistemin davranışı gözlenir.
Testler tatbikat kapsamında da yürütülebilir. Mor takım çalışmaları sırasında güvenlik kontrollerinden birinin devre dışı kalması senaryosu eklendiğinde, ekip hem teknik davranışı hem de müdahale sürecini birlikte sınamış olur.
İlk hata, hata yakalama bloklarında sessiz geçiş yapmaktır. Bir istisnanın yakalanıp yok sayılması, geliştirme sırasında kolaylık sağlar ama üretimde doğrulamasız işlem anlamına gelir. Yakalanan her istisnanın nasıl sonuçlanacağı açıkça yazılmalıdır.
İkinci hata, zaman aşımı davranışının tanımsız bırakılmasıdır. Bir doğrulama isteği yanıt vermediğinde ne kadar beklenip sonra ne yapılacağı belirlenmediğinde, davranış kütüphane varsayılanlarına kalır ve sistemler arasında tutarsızlaşır.
Üçüncü hata, acil durum geçiş yollarının kalıcılaşmasıdır. Kriz anında açılan bir bypass, sonrasında kapatılmadığında sistemin gerçek davranışı belgeden farklı hâle gelir; bu tür geçici çözümlerin son kullanma tarihi olmalıdır.
Kimlik altyapısı, arıza davranışının en kritik olduğu katmandır çünkü tüm erişim kararları buradan geçer. Kimlik sağlayıcısı erişilemez hâle geldiğinde uygulamaların ne yapacağı önceden kararlaştırılmalıdır: erişimi reddetmek mi, yoksa son bilinen oturumları bir süre daha geçerli saymak mı? İkinci seçenek iş sürekliliğini korur ama iptal edilmiş bir hesabın çalışmaya devam etmesi riskini taşır. Doğru denge, oturum ömrünün kısa tutulması ve kritik işlemler için katı davranışın korunmasıyla kurulur.
Aynı soru çok faktörlü doğrulama için de geçerlidir. İkinci faktörü doğrulayan servis yanıt vermediğinde sistemin yalnızca parolayla geçiş vermesi, kontrolü fiilen ortadan kaldırır. Bu davranış birçok üründe yapılandırılabilir olduğu için, kurulum sırasında bilinçli olarak seçilmelidir. Çok faktörlü kimlik doğrulama yatırımının değeri, tam da bu ayarın doğru yapılmasına bağlıdır.
Acil durum erişim yolları bu tasarımın tamamlayıcısıdır. Kimlik altyapısı tamamen erişilemez olduğunda kullanılacak, ayrı korunan ve kullanımı anında uyarı üreten hesaplar önceden hazırlanır. Bu hesapların parolaları ayrı bir kasada, ayrı bir onay süreciyle saklanır. Hazırlıklı olunmadığında, kriz anında güvenlik kontrolleri toptan devre dışı bırakılır.
Ağ tarafında arıza davranışı, cihazların konumlandırılma biçimiyle belirlenir. Satır arasında çalışan bir cihaz arızalandığında trafiği geçiren bir baypas anahtarı devrede olabilir; bu, erişilebilirliği korur ama denetimi kaldırır. Pasif dinleme konumundaki cihazlar ise arızalandığında trafiği etkilemez, yalnızca görünürlük kaybedilir. Hangi konumun seçileceği, ilgili segmentin kritikliğine göre kararlaştırılır.
Kural setinin yüklenememesi de ayrı bir senaryodur. Bir güvenlik duvarı yeniden başlatıldığında kural seti henüz yüklenmemişken trafiği geçirirse, kısa bir süre için de olsa tamamen açık bir pencere oluşur. Bu pencerenin kapatılması, cihazın kural seti hazır olmadan arayüzleri etkinleştirmemesiyle sağlanır. Üretici belgelerinde bu davranışın nasıl yapılandırıldığı mutlaka kontrol edilmelidir.
Yedekli mimari, katı davranışın uygulanabilir olmasını sağlar. İki cihazdan biri arızalandığında diğeri devraldığı için trafik durmaz ve fail-secure tercihi iş sürekliliğini tehdit etmez. Yedeklilik olmadan alınan katı kararlar, ilk kesintide gevşetilir. Bu nedenle arıza davranışı kararı ile mimari yedeklilik kararı birlikte verilir.
Şifreleme anahtarlarına erişilemediğinde sistemin ne yapacağı çoğu tasarımda atlanır. Anahtar yönetim servisi yanıt vermediğinde verinin şifresiz yazılması, güvenlik açısından kabul edilemez bir davranıştır. Doğru yaklaşım, işlemin reddedilmesi ve açık bir hata üretilmesidir. Bu davranışın uygulamada gerçekten geçerli olduğu test edilerek doğrulanır.
Yedekleme süreçlerinde de benzer bir karar gerekir. Yedek alınamadığında sürecin sessizce devam etmesi, aylar sonra fark edilen bir kurtarma boşluğu yaratır. Başarısız yedekleme işlemlerinin uyarı üretmesi ve belirli sayıda başarısızlıktan sonra yükseltilmesi gerekir. Yedeğin alınmış olması kadar, alınamadığının bilinmesi de kritiktir.
Kayıt yazımı da aynı mantıkla ele alınır. Kayıt hedefi erişilemez olduğunda uygulamanın kayıt üretmeden çalışmaya devam etmesi, o dönemi görünmez hâle getirir. Kritik sistemlerde yerel tampon kullanılarak kayıtların sonradan aktarılması tercih edilir. Tampon dolduğunda ne yapılacağı da ayrıca kararlaştırılmalıdır.
Arıza davranışı kararları dağınık biçimde değil, tek bir tabloda toplanır. Tablonun satırlarında bağımlılıklar, sütunlarında ise arıza türü, beklenen davranış, gerekçe ve telafi edici kontrol yer alır. Bu tablo mimari belgenin ayrılmaz parçası olur ve değişiklik yönetimiyle birlikte güncellenir. Tablosu olmayan sistemlerde davranış, kodun rastgele yerlerinde tanımlanmış olur.
Tablonun ikinci faydası, testlerin planlanmasını kolaylaştırmasıdır. Her satır bir test senaryosuna karşılık gelir ve dönemsel olarak sınanır. Sınama sonuçları aynı tabloya işlendiğinde, belge ile gerçeklik arasındaki fark açıkça görünür. Bu fark, çoğu kurumda ilk sınamada beklenenden büyük çıkar.
Privia Security olarak sistemlerin arıza anındaki davranışını siber tatbikat senaryolarına dahil ediyor, belgede yazan ile sahada gerçekleşen arasındaki farkı ortaya koyuyoruz.
Bunlar İlginizi Çekebilir