İki VPN katmanını üst üste koymalı mıyız? Kontrol edilecek üç koşul
İki VPN katmanı yalnızca farklı ana bilgisayarlarda biterse ve bağımsız anahtarlar kullanırsa yardımcı olur. Üç koşul, iç içe geçirmenin güvenlik mi yoksa yalnızca CPU maliyeti mi eklediğine karar verir.
Bir VPN'e ikinci bir şifreleme katmanı eklemeden önce bir soruyu dürüstçe yanıtlayın: iki katman da işini bitirdikten sonra gözlemcinin elinde ne kalır? Yanıt, değişmeden kalan iç şifreli metinse, iç içe geçirme zaman satın aldı ve başka bir şey almadı. Bundan sonrası bir öneri değil, bir karar prosedürüdür. Aynı şema bir dağıtımda boşa harcanmış CPU, diğerinde doğru yanıttır ve ikisini yalnızca üç koşul ayırır.
Gözlemcinin neyi sakladığını yazın
Bir saldırganın bugün saklayabileceği nesneyi kaydedin, ardından sonunda açık metni ortaya çıkaracak kaldırma dizisini kaydedin. Dış tünel şifreli metin üretir; koruması sona erdiğinde geriye kalan, iç tünelin hâlâ mühürlü olan şifreli metnidir. Bir sargıyı çıkarmak şifre çözmek değildir. O cümle iç içe geçirmeyi tanımlar ve yalnızca iç anahtar hayatta kaldığı sürece geçerlidir. İki katman herhangi bir şeyi paylaştığı anda, zaman çizelgesi tek bir olaya çöker.
Dolayısıyla işe yarar çıktı bir kutu şeması değil, bir zaman çizelgesidir. Her katman için uç noktayı, anahtarın sahibini, kimlik denetimini ve varsayımın başarısız olması beklenen yılı yazın.
Kendi iddianızı test etmenin pratik yolu: gözlemcinin her şeyi kaydettiğini ve asla pes etmediğini varsayın. Bu varsayım altında tasarım, gerekli ömrü boyunca yükü hâlâ koruyor mu? Yanıt, gözlemcinin trafiği saklamamayı seçmesine bağlıysa tasarımın yanıtı yoktur.
Koşul bir: katmanlar farklı yerlerde mi bitiyor?
İç içe geçirme, iki katman farklı güven alanlarında bittiğinde karşılığını verir; örneğin sağlayıcının yönettiği bir IPsec geçidi, kendi ağınızın içinde biten uygulama düzeyinde bir tünelin önünde. O zaman dış katmanı kırmak yalnızca ana bilgisayarınızın açabileceği şifreli metin verir ve sağlayıcı hiçbir noktada açık metin görmez. İki katmanı aynı geçide koyun, o özellik kaybolur. Kutuyu ele geçiren kişi, şema kaç sargı gösterirse göstersin, iki şifre çözme işlemi arasındaki trafiği okur.
Bunu tasarımla değil, kurulu durumla denetleyin. Linux'ta ip xfrm state her güvenlik ilişkisini ve uç noktalarını listeler; bu da her katmanın gerçekte nerede durduğunu belirler.
Koşul iki: anahtar malzemesi gerçekten bağımsız mı?
Tek bir sertifikadan, tek bir önceden paylaşılan anahtardan veya tek bir satıcı kitaplığından oluşturulan iki katman, fazladan adımları olan tek bir katmandır. O zaman tek bir ele geçirilmiş kimlik bilgisi ikisini de açar ve tek bir uygulama hatası ikisini birden kaldırır. Bağımsızlık yapılandırmada görünmelidir, slaytta iddia edilmemelidir.
Hibrit anahtar kurulumu burada tünelleri üst üste yığmayı geride bırakır. IKEv2 tek bir görüşmede birkaç anahtar değişimini taşıyabilir, böylece klasik bir grup ve kuantum sonrası bir KEM aynı oturum anahtarlarını besleyebilir, birbirinin etrafına sarılmak yerine. Sonuç, anahtarları iki sırra da bağlı olan tek bir güvenlik ilişkisidir ve saldırgan ikisini de kırmak zorundadır. Bu, tanımlanmış bileşimi olan belgelenmiş bir yapıdır; iki VPN ürününden yapılmış ev yapımı bir yığın ise öyle değildir. strongSwan'da swanctl --list-sas her SA için görüşülen öneriyi yazdırır ve böylece neyi yapılandırdığınızı değil, gerçekte neyin çalıştığını doğrularsınız.
Koşul üç: veriler dış varsayımdan daha uzun yaşıyor mu?
Yirmi yıl dayanması gereken bir katman yirmi yıllık bir argüman gerektirir. Şimdi kaydedip sonra şifresini çözmek ucuzdur ve bu yüzden klasik bir dış katman, daha güçlü bir şeyin etrafındaki geçici bir sargı olarak görülemez.
Her anahtarın ne zaman kurtarılabilir hale geldiğini sorun, şifrenin bugün kırılıp kırılmadığını değil. İleriye dönük gizliliği olmayan statik anahtar değişimi, özel anahtarın düştüğü gün geriye dönük olarak başarısız olur. Geçici anahtar anlaşması yalnızca saldırganın canlıyken saldırabildiği oturumlar için ya da algoritmanın kendisi zayıfladığında başarısız olur. Bu fark, iç katmanın 2040'ta hâlâ yardımcı olup olmadığına karar verir. Aynı zamanda dış katmanın herhangi bir şeyi değiştirip değiştirmediğine de karar verir, çünkü daha zayıf anahtar ömrüne sahip dış katman zaman çizelgesindeki en erken nokta haline gelir.
Yanıt hayır olduğunda yerine ne inşa etmeli
Üç koşuldan herhangi biri başarısız olursa iç içe geçirmeyi bırakın ve çabayı ömür gereksinimini gerçekten taşıyan katmana harcayın. Zaten çalıştırdığınız protokolde hibrit anahtar değişimini yapılandırın, uygulamayı güncel tutun ve güvendiğiniz bileşimi yazın. Bir tasarım belgesinde ML-KEM adını anmak bir güvenlik özelliği değildir ve FIPS 203 anahtar kapsülleme mekanizmasını tanımlar, tünelinizi değil.
İkinci katmanın yerini gerçekten kazandığı yerde, onu kanıt olarak değil, derinlemesine savunma olarak tanımlayın. Ardından bileşimi doğrulayın: hangi uç nokta hangi anahtarı tutuyor, her taraf hangi kimliği denetliyor ve konsol erişimi olan bir operatör neyi okuyabiliyor. Bu üç soruyu atlatan bir tasarım fazladan CPU'ya değer. Atlatamayan ise yalnızca bir şemadır.
Değişiklik penceresinden önce mevcut SA tablosunu ve görüşülen önerileri kaydedin, sonrasında yeniden kaydedin ve karşılaştırın, çünkü önemli olan tek kanıt cihazların gerçekte ne üzerinde anlaştığıdır.