VPN arkasındaki SaaS yönetim alanı: hangi adrese güvenmeli?

Kaynak, laptopun tünel adresini değil VPN ağ geçidinizin çıkış adresini görür. Yalnızca yapılandırılmış bir proxy başlığına güvenin, sonra her yönetim işlemini kapıdan geçirin.

Genel SaaS sayfaları herkese açık kalabilirken arkalarındaki yönetim işlemleri VPN dışındaki herkesi reddeder. Bunu mümkün kılan mekanizma gizli bir menü ya da ayrı bir giriş sayfası değil; isteği teslim eden ağ yolunun denetimidir. Adres kanıtını yanlış alırsanız denetim ya gerçek yöneticileri kilitler ya da başlık yazabilen herkesi içeri alır. Kaynağın gerçekte ne aldığıyla başlayın.

Tünelden sonra kaynağın gerçekte ne aldığı

Bir tarayıcı internet trafiğini de taşıyan bir VPN üzerinden genel siteye ulaştığında, ağ geçidi bağlantıyı dışarı çıkmadan önce çevirir. SaaS ağ geçidinin genel çıkış adresini görür, genellikle tek bir adres ya da küçük bir aralık, ve laptopun tünel adresini asla görmez. Bu yüzden 10.90.0.42 adresini izin listesine eklemek başarısız olur ve bu yüzden RFC 1918'in tamamını eklemek daha da yüksek sesle başarısız olur: ikincisi size ulaşabilen her özel ağı içeri alır. Koşul koymaya değer tek adres, kuruluşunuzun çıkışta gerçekten sahip olduğu adrestir.

curl -s https://ifconfig.me
dig +short admin.example.com

Bölünmüş tünelleme bu varsayımı sessizce kırar. VPN yalnızca özel ofis rotalarını taşıyorsa, genel yönetim ana makine adına yapılan istek yerel sağlayıcıdan çıkar ve kaynak konut adresi görür. Bağlı bir VPN simgesi bu belirli hedef hakkında hiçbir şey kanıtlamaz, bu yüzden tüneli değil hedefi test edin.

Çıkış adresi kullanıcıya göre değişiyorsa herhangi bir politika yazmadan önce durun ve yönlendirmeyi düzeltin. Yalnızca bazı yöneticilere uyan bir koşul hiç koşul olmamasından daha kötüdür, çünkü bir olaya kadar sorunu gizler.

Yalnızca adresi yeniden yazan proxy'ye güvenin

Genel sitelerin çoğu bir CDN ya da ters proxy arkasındadır, bu yüzden kaynağın soket adresi ziyaretçiye değil o ön yüze aittir. Ön yüz genellikle özgün adresi bir başlıkta iletir, ve kaynak o başlığı yalnızca bilinen proxy'lerden kabul etmiyorsa başlık saldırganın kontrolündedir. Güvenilir kaynak listesini açıkça yapılandırın ve kaynağı başka her yerden erişilemez yapın. O ikinci yarı olmadan saldırgan proxy'yi atlar ve başlığı doğrudan gönderir.

set_real_ip_from 192.0.2.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
curl -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin

Aynı akıl yürütme PROXY protokolü için de geçerlidir: yalnızca dinleyici proxy'nin ulaşabildiği ve başka hiçbir şeyin ulaşamadığı bir arayüze bağlı olduğunda güvenilirdir. Eksik adres bağlamı korumalı denetimi başarısız kılmalı, varsayılan bir izne düşmemelidir. Eksik bir başlık güvenilir bir yolun kanıtı değildir.

Koşulu her korumalı işleme ekleyin

Denetimi menüyü oluşturan sayfaya değil, her korumalı işlemin geçtiği yetkilendirme sınırına koyun. Rota grupları, ara yazılım ya da bir politika katmanı hepsi çalışır; işleyici başına kopya çalışmaz, çünkü gelecek çeyrekte birinin eklediği işleyicide o olmayacaktır.

user = requireAuthenticatedSession()
requirePermission(user, "admin")
requireVpnEgress(verifiedClientAddress(request))
performProtectedOperation(user, request)

Aynı sınır JSON API'sini, dışa aktarımları, imzalı indirme URL'lerini ve WebSocket el sıkışmasını da kapsamalıdır, çünkü hiçbiri önce HTML sayfasının istenmesini gerektirmez. VPN açıkken oluşturulan indirme bağlantısı, indirme uç noktası yeniden denetlemedikçe sonrasında da geçerli kalır. Uzun ömürlü oturumlar da yeniden değerlendirme kuralına ihtiyaç duyar, yoksa bir kimliği doğrulanmış istek kalıcı bir istisnaya dönüşür. Varsayılan reddetme, personel değişimini atlatan tek ayardır.

Paylaşılan önbellekler denetimin etrafındaki diğer yoldur. Korumalı bir yanıtı zaten tutan bir önbellek, kaynağa başvurmadan onu sunabilir, bu yüzden yönetim yanıtlarını özel olarak işaretleyin ve paylaşılan depolamanın dışında tutun. Bir önbellek bunları sunmak zorundaysa, erişim denetimi sunumdan önce çalışmalıdır; bu da genellikle hiç paylaşılan önbellek olamayacağı anlamına gelir.

Az önce kapattığınız atlatmaları test edin

Mutlu yolu değil matrisi çalışın: VPN üzerinden bir yönetici, o olmadan aynı yönetici, onun üzerinden yönetici olmayan biri ve sahte bir adres başlığı. Doğrudan kaynağa bir istek ve önbelleğe alınmış yanıtlı bir istek ekleyin, çünkü ön yüzü tamamen atlayan bu ikisidir.

curl -sI https://admin.example.com/export.csv
curl -s -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin
curl -s https://admin.example.com/api/me -o /dev/null -w '%{http_code}\n'

Her istek politikanın vaat ettiği durumu döndürmeli ve günlük hangi adres kanıtının kullanıldığını kaydetmelidir. IPv6'yı ayrıca kapsayın, çünkü çift yığınlı bir kaynak test ettiğinizden farklı bir kaynak ailesi görebilir. Olağan müşteri işlemlerini VPN dışında çalışır tutun, yoksa değişiklik bir müşteri ilk kez şikâyet ettiğinde geri alınır. Sürpriz bir geçiş görünür olsun diye her satırın beklenen sonucunu çalıştırmadan önce yazın.

Çıkış adresi izin verilen bir ağ yolunu kanıtlar, bir kişiyi ve yönetilen bir cihazı değil. Onu kimlik doğrulama ve iznin yanında tek bir koşul olarak tutun, yönetim alanı tüm ürünü yalnızca VPN hizmetine dönüştürmeden dar kalır. Bu ayrım tasarımın kendisidir, onun bir kısıtı değil.

İlgili makaleler