VPC uzaktan erişimini kabul etmek ret testleri gerektirir

Uzaktan erişimin kabulü, çalışan bir sayfanın ekran görüntüsü değil, beklenen sonuçların tablosudur. Her grup için neyin başarılı olması ve neyin başarısız olması gerektiğini yazın, sonra ikisini de kontrollü bir zaman aralığında ayrılmış test kimlikleriyle çalıştırın. Sınırı kanıtlayan kısım redlerdir; başarılı bir oturum yalnızca tünelin var olduğunu kanıtlar. Bunların hepsi zaten seçilmiş VPN ürünüyle çalışır.

Testler için ayrı hesaplar kullanın ve test kimliğini gerçek bir istisnayla kimsenin karıştırmayacağı şekilde etiketleyin.

Sınırı beklenen sonuçlar olarak yazın

Bileşenlerden değil rollerden başlayın: kim hangi hizmete, nereden ve hangi kimlikle ihtiyaç duyuyor. Örnek bir VPC alın: bir grup HTTPS üzerinden test ortamına ihtiyaç duyar, bir diğeri üretim veritabanına ihtiyaç duyar ve üçüncü ve daha küçük grup ağ geçidini kendi yönetir. Her satır beklenen bir izin ve beklenen bir ret alır; çalışmaması gereken komşu hizmet ve komşu hesap da buna dahildir. O tablo kabul ölçütüdür ve testleri çalıştırmayan kişiler de onu gözden geçirebilir.

Veritabanı oturumunu ağ yolundan ayrı test edin. Erişilebilir bir TCP bağlantı noktası, onaylanmamış bir veritabanı hesabının başarılı olmasına yol açmamalıdır ve VPN üyeliği bir bulut IAM rolü oluşturmamalı veya yönetimsel API erişimi vermemelidir. Bunlar üç bağımsız kontroldür ve bağımsız olarak başarısız olurlar.

Rota yetkilendirme değildir

Bir rota yolu mümkün kılar; izin vermez. Bir rotayı esirgemek, hedefte uygulanan kısıtlamanın zayıf bir yerine geçenidir, çünkü istemci her zaman kendi rotasını ekleyebilir. Güvenlik grubu, veritabanı izni ve uygulamanın kendi yetkilendirmesi karar veren kontroller olarak kalır. Bir test beklenmedik şekilde başarılı olduğunda önce hedefin politikasına bakın, istemcinin sahip olmasını istediğiniz yönlendirme tablosuna değil.

Bu yüzden ret testleri sunucu tarafını hedefler: o sonuçlar istemci düzenlenerek değiştirilemez.

Kontrol gerçekte hangi kaynağı görüyor?

Bir kontrolün değerlendirdiği kaynak adresi ağ geçidi mimarisine bağlıdır. EC2 üzerinde barındırılan bir ağ geçidi yönlendirilmiş bir havuzu iletebilir, kendi adresine çevirebilir veya NAT sonrasında farklı bir adres sunabilir; yönetilen Client VPN bir alt ağa bağlanır ve kendi modelini izler. Güvenlik grupları ve ağ ACL'leri bu işlemeden sonra geleni görür. Bir kuralı yanlış kaynak varsayımıyla incelemek, doğru görünen ama yanlış trafiği geçiren bir sınır kurmanın yaygın bir yoludur.

Her sonucu en küçük yararlı olayla ilişkilendirin: kimlik ve oturum, kaynak, işlem, zaman ve karar. CloudTrail'deki bir API çağrısı, bir VPC akış kaydı ve bir VPN oturum günlüğü farklı soruları yanıtlar ve hiçbiri tek başına bir uygulama denetimi değildir.

Bir kimliği geri çekin ve yeniden test edin

Geri çekmeyi aynı tabloya dahil edin. Bir test kimliğini kaldırın, yeni bir oturumun reddedildiğini doğrulayın, sonra mevcut oturumlara nasıl davranıldığını ayrıca doğrulayın, çünkü bunlar farklı sahiplere ait farklı davranışlardır. Ağ geçidinin yeniden başlatılmasından veya değiştirilmesinden sonra ne olduğunu kontrol edin, böylece elle eklenen bir istisna sessizce kaybolmaz veya daha geniş olarak geri dönmez. Yalnızca bir sonraki dağıtıma kadar süren bir sınır, sınır değildir.

Bunların hiçbiri yama, kurtarma veya kimlik bilgisi yaşam döngüsü çalışmasının yerini almaz. Daha dar bir vaadi ölçülebilir kılar: doğru kişiler doğru hizmetlere ulaşır, yakındaki rotalar, hesaplar ve yönetim yüzeyleri ise iznin dışında kalır.

Tabloyu dağıtımla birlikte saklayın ve ağ geçidi değiştiğinde yeniden çalıştırın. Testler ucuzdur; arkalarındaki varsayımlar değil.