EC2 için yalnızca VPN kuralı: bağlı her güvenlik grubu aynı fikirde olmalı

VPN istemci havuzu için tek bir gelen kuralı eklersiniz, hiçbir şeyi kaldırmazsınız ve hizmet hâlâ internetten erişilebilir. Hiçbir şey bozulmamıştır. Bir güvenlik grubunda dar kuralın karşısında kazanabileceği bir geçersiz kılma, öncelik veya nihai ret yoktur. Örneğe bağlı her grup, kendi izinlerini tek bir birleşik kümeye ekler ve unuttuğunuz geniş kural hâlâ o kümede durur. Örneği yalnızca VPN yapmak, hepsini denetlemek demektir; birine daha iyi kulağa gelen bir kural eklemek değil.

Kuralı yazmadan önce hizmeti yazın

Kesin hedef, protokol ve bağlantı noktasıyla ve hizmetin gerçekte dinlediği ağ arabirimiyle başlayın. Birden çok arabirimi veya tek bağlantı noktasında birden çok hizmeti olan bir örnek, bağlı gruplar farklı olabileceği için denetimin her arabirim için yapılmasını gerektirir. Ardından, o arabirimin bir VPN kullanıcısı için gerçekte hangi kaynak adresini aldığını istemcinin kendi bağlantı penceresinde gösterdiği adres yerine belirleyin.

Çeviri ve yönlendirme işin içine girdiğinde bu iki adres, insanların beklediğinden daha sık ayrışır.

Üç kaynak modeli, üç farklı kural

Özel yönlendirilmiş erişimde örnek, yolun nasıl yönlendirildiğine ve çevrildiğine bağlı olarak istemci havuzunu veya kurumsal aralığı alır. Kurumsal çıkış üzerinden erişilen genel bir uç noktada örnek bunun yerine kurumsal NAT adresini görür ve yalnızca o hedef gerçekten VPN yolunu kullanıyorsa, çünkü bölünmüş tünelleme onu bir ev bağlantısında bırakabilir. Yönetilen bir Client VPN uç noktasında belgelenmiş ilişkilendirme ve hedef ağ modeli geçerlidir ve istemci adresi yapılandırılmış istemci CIDR'inden gelir.

İşe yaramayan şey, bir VPN ağ geçidini güvenlik grubu kaynağı olarak göstermektir. Grup referansları VPC veya eşlenmiş bir ağ içindeki elastik ağ arabirimleriyle eşleşir ve paketleri ileten bir ağ geçidi bunlardan biri değildir.

Bağlı her gruptaki birleşimi okuyun

Örneği açın, ağ arabirimini bulun ve ona bağlı her güvenlik grubunu listeleyin. Her biri için protokolünüzü ve bağlantı noktanızı kapsayan her kuralı denetleyin; geniş bağlantı noktası aralıkları ve her iki adres ailesi dâhil. 0.0.0.0/0'dan gelen bir IPv4 kuralı sizi ::/0'ı denetlemekten muaf tutmaz ve tüm trafiğe izin veren bir kural bağlantı noktası sorusunu tamamen gizler. Ancak bu envanterden sonra hizmet için etkili iznin ne olduğunu söyleyebilirsiniz.

AWS kural başvurusu güvenlik gruplarını yalnızca izin veren olarak tanımlar ve bağlı tüm grupların kurallarının birleştirildiğini belirtir; bu hatanın arkasındaki tüm mekanizma budur.

Ağ ACL'leri, sıralı izin ve ret girdileri olan ayrı ve durumsuz bir ilkedir ve örnekte değil alt ağda değerlendirilir.

Ret duvarıyla yanıt vermeyin

Alıştığınız bir güvenlik duvarını taklit etmek için alt ağ çapında bir NACL reddi eklemek yanlış araçtır ve risklidir. NACL girdileri sıralı ve durumsuzdur, bu yüzden mevcut bir iznin üstüne konan bir ret, tutmaya çalıştığınız oturumların dönüş yolu dâhil, ilgisiz trafiği sessizce bozar. Geniş güvenlik grubu iznini ona sahip olan grupta düzeltin, sonra ACL gerçekten tasarımın parçası değilse onu rahat bırakın.

Örnekten genel bir adresi kaldırmak daha güçlü bir güvencedir ve aynı zamanda yönetimsel ve uygulama sonuçları olan bir mimari değişikliktir; izin listesindeki bir onay kutusu değildir.

Yeni bir oturumla test edin ve içeri girmenin bir yolunu koruyun

Mevcut bir izni kaldırmadan önce onaylanmış bağımsız bir yönetim yolu doğrulayın, çünkü silmek üzere olduğunuz kural oturum kurtarmanızın bağlı olduğu kural olabilir. Ardından VPN'den yeni izin verilen bir bağlantıyı ve yetkili bir VPN dışı test yolundan yeni reddedilen bir bağlantıyı test edin. Mevcut izlenen oturumlar kural değişikliklerini öyle atlatır ki eski açık kabuklar kabul kanıtı olarak işe yaramaz hâle gelir.

Son olarak, uygulamanın kendi yetkilendirmesini yerinde tutun. Çevrilmiş bir kurumsal çıkış yüzlerce insanı temsil edebilir ve ağa kabul hiçbir zaman tek bir kullanıcıyı veya cihazını tanımlamadı.