Tek bir bulut hizmeti için yerel TLS, SSH yönlendirmesi veya VPN

Soru nadiren iki bulut makinesi arasında bir şeyin şifrelenip şifrelenmeyeceğidir; soru hangi arayüzü şifrelediğiniz ve kimin kimin kimliğini doğruladığıdır. Bu konuşmalara ağ diyagramından değil hizmetten başlıyorum, çünkü hizmet neye ihtiyacı olduğunu zaten biliyor. Üç sınır çoğu durumu kapsar: uygulamanın kendi TLS'i, SSH üzerinden yönlendirilen tek bir TCP bağlantı noktası ve her katılımcıya adres veren yönlendirilmiş bir katman. Güce göre değil, sorunun ne kadarını kapsadıklarına göre sıralanırlar.

Ağdan değil hizmetten başlayın

Süreçten dışarı doğru gidin. Hangi protokolü konuşuyor, istemci hangi adı doğrulayacak ve kimin bağlantı açmasına izin var? Bu üç yanıt seçenekleri herhangi bir karşılaştırma tablosundan daha hızlı eler ve hizmetin kendi yapılandırması genellikle bunları birkaç dakika içinde yanıtlar.

8443 numaralı bağlantı noktasında zaten HTTPS sunan küçük bir iç API alın, api.internal.example için bir sertifikayla. Ana bilgisayardaki ss -ltnp neye bağlandığını gösterir ve openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example sertifikanın istemcinin gerçekte kullanacağı ad için geçerli olup olmadığını gösterir. İkisi de sağlıklıysa hizmet kendi akışını koruyabilir ve geriye yalnızca erişilebilirlik kalır. Bu, ağ kurmaktan çok daha küçük bir sorundur.

Adım 1: hizmet kendini koruyor mu?

Bu, uygun olduğunda seçilecek seçenektir ve ekiplerin varsaydığından daha sık uygundur. Hizmetin şifrelemesi istemci ile sunucu arasındaki tüm yolu, aradaki her sıçrama dahil kapsar; bunu ortadaki hiçbir tünel iyileştirmez. Beklenen adı ve güveni açıkça ayarlayın, istemcinin varsayılan deposunda tesadüfen ne varsa ona güvenmek yerine.

Şifreleme ve erişilebilirlik ayrı kontroller olarak kalır ve bunları birleştirmek bu seçeneğin yanlış gittiği yerdir. Kısıtlanmamış bir genel dinleyicideki TLS hizmeti hâlâ herkesten bağlantı denemesi kabul eder, bu yüzden dinleyici ve ağ kuralları yükün korunmasından bağımsız olarak tanımlanmalıdır. Ardından bağımlılıkları kontrol edin, çünkü TLS üzerindeki bir API keşif uç noktası, yönetici bağlantı noktası veya yanındaki toplu aktarım kanalı hakkında hiçbir şey söylemez. Her biri kendi yanıtına ihtiyaç duyar ve korumasız tek bir kardeş tüm sınırı kurgu yapmaya yeter.

Adım 2: tek bir TCP bağlantı noktası tüm gereksinim mi?

Gereksinim gerçekten tek bir TCP bağlantı noktasıysa, yönlendirme işe yarayan en küçük şeydir. Yerel SSH yönlendirmesi o bağlantı noktasını zaten var olan kimliği doğrulanmış bir bağlantı üzerinden taşır.

Biçim ssh -N -L 8443:127.0.0.1:8443 [email protected] ve önemli ayrıntı hedef adres: 127.0.0.1 uzak tarafta çözülür, bu yüzden hizmete bağlantı dizüstü bilgisayarınızdan değil bastion'dan açılır. Yerel dinleyiciyi -L 127.0.0.1:8443:... olarak dar biçimde bağlayın, böylece hizmeti kendi yerel ağınızda yanlışlıkla yayınlamazsınız. Sunucu tarafında, istemcinin iyi davranacağına güvenmek yerine hesabın neleri yönlendirebileceğini sınırlayın. PermitOpen, AllowTcpForwarding local ve varsayılan GatewayPorts no, genel bir aktarıcıyı belirli bir kanala dönüştüren üç ayardır.

Sözleşme her iki yönde de dar. SSH kendi kanalını korur ve bastion'dan başka bir uygulamaya yapılan ek sıçrama kendi korumasına ihtiyaç duyar. Yalnızca bastion'un loopback'inde dinleyen bir hizmet, başka bir ağ üzerinden erişilen hizmetten tamamen farklı bir maruziyete sahiptir ve yönlendirme bunu değiştirmez. Tüneli bunların yerine koymak yerine uygulamanın kimlik doğrulamasını ve TLS kontrollerini koruyun.

Bu, tek sahipli tek bir bağlantı için iyi çalışır. Ölçekte bir sisteme dönüşür: yerel bağlantı noktası çakışmaları, gözetim, anahtar döndürme ve yeniden başlatmadan sonra yönlendirmeyi kimin yeniden başlatacağı sorusu.

Adım 3: yönlendirme gerçek gereksinim mi?

Bu liste en küçük seçeneğin dürüst maliyetidir ve bu yüzden ekipler sonunda unutulmuş birkaç arka plan komutunu yönetilen bir şeyle değiştirir. Değiştirme otomatik olarak VPN değildir. Gereksinim hâlâ tek bir TCP bağlantı noktasıysa, belgelenmiş sahibi olan gözetimli bir yönlendirme katmandan daha ucuza çalışır ve görebileceğiniz biçimlerde başarısız olur. Zarafeti ölçmeden önce operasyonel sahipliği ölçün.

Yönlendirme gereksinim olduğunda yönlendirme doğru yanıt olur. Sıradan IP bağlantısına ihtiyaç duyan birkaç uygulama, TCP yönlendirmesinin taşıyamayacağı protokoller veya ana bilgisayarlar arasında taşınan hizmetler hep aynı yönü gösterir.

Katman katılımcılara adres ve rota verir, sonra gerçek iş başlar: çakışmayan aralıklar, rota sahipliği, DNS, kayıt, iptal ve bir eş kaybolduğunda ne olacağı. Bunların hiçbiri adresle birlikte gelmez. Katmana kabul edilen bir eş de hedefteki her işlem için otomatik olarak yetkilendirilmiş değildir, bu yüzden hizmet düzeyinde kimlik doğrulama kalır.

Sonrasında neye sahipsiniz

Bıraktığınız kayda iki şey aittir. Birincisi istemcinin doğrulaması beklenen kimliktir, çünkü bir şeyi çalıştırmak için ad kontrolü gevşetildiğinde bu sınırların her biri sessizce bozulur. İkincisi kaldırma adımıdır: erişim bittiğinde hangi anahtar, hangi kural veya hangi rotanın kaybolacağı ve bunu kimin yapacağı.

Bu yolculuk başladığı yerde, hizmette biter. Gerçek trafiği kapsayan ve doğrulamayı amaçladığınız eşleri doğrulayan sınırı seçin, ardından erişimin nasıl güncellendiğini, izlendiğini ve kaldırıldığını yazın. OpenSSH başvurusu dar bir sözleşme vaat etmeden önce yönlendirme seçeneklerini doğrulayacağınız yerdir. Kaldırma adımını tek bir cümlede tanımlayamıyorsanız, sınır sorundan daha büyüktür.