Saha cihazlarında TLS ve VPN: hangi sınır neyi korur

Bir saha cihazı bir hizmete bağlantı açar ve tasarım sorusu bir VPN ile TLS arasında seçim olarak gelir. Bu çerçeveleme yanlıştır, çünkü ikisi farklı işler yapar. TLS uygulama uç noktasının kimliğini doğrular ve görüşmeyi korur; bir VPN ise erişilebilirliği denetler ve eşler arasındaki paketleri korur. Bağlantıyı cihazdan dışa doğru izleyin; her katmanın kendi yanıtı vardır.

TLS'in nerede sonlandığını söyleyemiyorsanız, uygulamanın gerçekte neye güvendiğini de söyleyemezsiniz.

TLS'in gerçekte nerede sonlandığını bulun

Cihazdaki uygulamadan başlayın ve bağlantıyı el sıkışmayı tamamlayan sürece kadar izleyin. Bir vekil sunucu TLS'i ana bilgisayardan önce sonlandırıyorsa, korunan yol bu vekilde biter. Geriye kalan atlama kendi belgelenmiş korumasına ihtiyaç duyar.

Varsayımla buna uçtan uca demek, bir tasarım incelemesinin açığı onaylamasının yoludur. Sonlandırma noktasını ve güven çapasını aynı şemaya çizin.

TLS istekleri ve yanıtları her iki yönde taşır; bu nedenle çift yönlü bir uygulama doğası gereği TLS yerine VPN'e ihtiyaç duymaz. Tersi de doğrudur: bir kurulum, aynı cihazdaki diğer protokoller için yine de VPN'e ihtiyaç duyabilir.

Cihazın neyin kimliğini doğrulaması gerektiğine karar verin

Sunucu kimliği doğrulamasını ve amaçlanan güven köklerini yapılandırın. Her cihaz kendi kimliğini kanıtlamak zorundaysa, desteklenen bir istemci kimlik doğrulama modeli seçin ve her cihaz için ayrı bir kimlik bilgisi kaydedin. Paylaşılan kimlik bilgileri, çalınan tek bir cihazı filo çapında bir soruna dönüştürür.

Sevkiyattan önce anahtar korumasını, yenilemeyi, iptali ve kurtarmayı planlayın. Sahada bir yenileme başarısız olduktan sonra yeniden kaydedilemeyen bir cihaz, bir saha ziyaretine dönüşür ve bu maliyet tasarımı el sıkışmadan daha çok şekillendirir.

Desteklenen bir kitaplık ve güncel kılavuz kullanın. Modern TLS dağıtım kılavuzu TLS 1.0 ve 1.1 ile anlaşmayı yasaklar; eski bir tasarım notundaki TLSv1 atfı bir gereklilik değildir.

El sıkışma başarısız olduğunda kapalıya düşün

Başarısız bir el sıkışma veya kimlik denetimi, sessizce özgün düz metin protokolüne geri dönmemelidir. Bu geri dönüş, TLS çalışmasının kapatmayı amaçladığı güvenlik açığıdır. Hatayı cihaz operatörüne ve hizmete görünür kılın ve hassas işlemler için korunan kanalı zorunlu tutun. Ardından kimliği doğrulanmış bir cihazın neler yapabileceğine uygulama yetkilendirmesi karar versin.

Bağlantı ömrünü, çerçevelemeyi, zaman aşımlarını ve yeniden deneme davranışını sözleşmenin parçası olarak tanımlayın. Şifreleme, tekrarlanan bir komutu güvenli kılmaz ve önceki işlemin sonucu belirsizken yapılan yeniden deneme uygulama düzeyinde bir yanıt gerektirir.

Geri dönüş kuralını yazın. "El sıkışma başarısız olursa TLS olmadan yeniden bağlanır" bir tasarım kararıdır ve açıkça belirtilen bir karar olmalıdır.

VPN'e yalnızca yapabildiği işi verin

Bir VPN erişilebilirliği kısıtlayabilir ve kendi eşine giden paketleri koruyabilir. TLS ise uygulamanın seçilen uç noktayla ilişkisini korur. Sonlandırma noktaları farklı olabilir ve ikisi de uç noktanın depolanan verilerini ya da yönetim erişimini güvence altına almaz.

El sıkışma maliyetini, kararlı durumdaki mesajlaşmayı ve yeniden bağlanmayı bir mekanizmanın daha hızlı olduğunu varsaymak yerine gerçek cihazda ölçün. Ardından önemli olan dört durumu test edin: amaçlanan alışveriş, yanlış sunucu kimliği, yetkisiz bir cihaz ve sonucu belirsiz bir işlemin ardından yeniden bağlanma. Her durum için sonucu, cihazın gösterdiği hata dahil, kaydedin.