HTTP yayınını uygulama yürütmesinden ve kalıcı verilerden ayırın. Ters proxy yönlendirmeyi ve sınırları düzenleyebilir, ancak kaynak erişimi, uygulama yetkilendirmesi, üst kaynak kapasitesi ve kurtarma her biri kendi kontrollerini gerektirir.
Bir web isteği birkaç sorumluluk alanından geçer
Bir web sunucusu HTTP isteklerini alır ve statik dosyaları sunabilir. Bir uygulama süreci, hesap kontrol etme veya veritabanı sorgulama gibi projenin dinamik davranışını yürütür. Bir ters proxy, bu süreç adına istekleri alır ve bunları bir üst kaynağa iletir. Tek bir program birkaç rolü yerine getirebilir, ancak sorumlulukları ayırmak yapılandırma ve kurtarma hakkında akıl yürütmeyi kolaylaştırır.
Ana makine adı çözümlemesinden yanıta kadar bir isteği izleyin. TLS'ın nerede bittiğini, hangi sürecin rotayı seçtiğini ve hangi bileşenin uygulama verilerini okuyabildiğini kaydedin. Aynısını bir yönetim isteği için de yapın. Bu alıştırma genellikle test için oluşturulmuş ve yanlışlıkla erişilebilir kalmış bir dinleyiciyi veya ana makine adını ortaya çıkarır. Diyagram, oluşturmayı umduğunuz mimariyi değil, dağıtılan yolu tanımlamalıdır.
HTTP davranışını düzenlemek için sınırı kullanın
NGINX hem statik içerik sunmayı hem de istekleri bir üst kaynağa iletmeyi belgeler. Çalışan mimarisi ve HTTP modülleri yapılandırma mekanizmaları sağlar, ancak belirli bir yapılandırma yine de davranışı belirler. Ana makine adlarını, üst kaynakları ve dosya sistemi köklerini kasıtlı olarak tanımlayın. Sunulabilecek dosyaları kısıtlayın; böylece yapılandırma, kimlik bilgileri ve depo meta verileri, uygulamanın yanında bulundukları için indirilebilir hale gelmesin.
Uygulamaya göre istek gövdeleri, zaman aşımları ve bağlantılar için uygun sınırlar belirleyin. Önbellekleri bir veri kararı olarak ele alın: bir kullanıcıya veya izne bağlı içerik, incelenmeden paylaşılan bir önbellekleme kuralını güvenle devralamaz. Kimlik doğrulama ve önbellek davranışını birlikte test edin. Yeniden üretilebilir bir yapılandırma tutun ve hizmeti yeniden yüklemeden önce değişiklikleri doğrulayın; önceki çalışan sürüme dönüş yolu bilinsin.
| Katman | Yararlı sorumluluk | Başlatmadan önce kontrol edin |
|---|---|---|
| Genel web sınırı | TLS, ana makine adı yönlendirmesi ve HTTP sınırları | Sertifikalar, kökler ve amaçlanan ana makine adları |
| Uygulama süreci | İş mantığı ve yetkilendirme | Kimlik doğrulama, girdi kontrolleri ve bağımlılık hatası |
| Dahili veri hizmeti | Kalıcı uygulama durumu | Kısıtlı erişim ve test edilmiş geri yükleme |
| Üst sağlayıcı ağı | Sözleşmeli ağ hizmeti | Koruma kapsamı ve yükseltme yolu |
Ters proxy, kaynağın maruziyetini ortadan kaldırmaz
Kaynak genel olarak erişilebilir kalırsa, bir istemci amaçlanan proxy rotasını kullanmadan ona ulaşabilir. Dağıtım bu sınırı gerektirdiğinde, kaynak erişimini ağ tasarımı ve uygulama yapılandırması aracılığıyla kısıtlayın. Tek bir makinede, bir arka uç genellikle loopback veya yerel bir soket üzerinde dinleyebilir. Makineler arasında, açık kısıtlı rotalar ve üst bağlantı için uygun koruma kullanın.
İletilen başlıkların da bir güven kuralına ihtiyacı vardır. Orijinal istemci hakkındaki bilgileri yalnızca güvenilir aracılardan kabul edin ve rastgele çağıranların uygulamanın yetkili saydığı değerleri sağlamasını önleyin. Erişim günlüklerinde ve hata raporlarında ne görüneceğine karar verin. Bir proxy her katmanda mevcut bilgiyi değiştirebilir; hesap tanımlayıcılarını silmez veya uygulamayı kendi operatörüne karşı anonim hale getirmez.
Erişim kararlarını uygulama içinde uygulayın
NIST'in Zero Trust mimarisi, yalnızca ağ konumuna dayalı örtük güven yerine kaynaklar için erişim kararlarına odaklanır. Bu ilkeyi somut olarak uygulayın: çağıranın kimliğini doğrulayın, istenen işlemi yetkilendirin ve hizmet hesaplarına yalnızca gereken kapsamı verin. Dahili bir alt ağdan gelen bir istek otomatik olarak yönetici isteği haline gelmemelidir.
Mümkün olduğunda genel ve yönetim işlevlerini ayırın. Bir kullanıcı bir kayda eriştiğinde, yalnızca ilk oturum açmaya güvenmek yerine izni yeniden kontrol edin. Proxy, uygulama ve veritabanı için kimlik bilgilerini ayrı tutun. Değişiklikleri, test edilebilen aşamalarda, dar ve hassas bir yolla başlayarak sunun. Bir dağıtımı Zero Trust olarak adlandırmak, yasak bir eylemin gerçekten ondan sorumlu bileşende reddedildiğini göstermekten daha az yararlıdır.
Hizmet reddini birden fazla katmanda planlayın
Doymuş bir ağ bağlantısı ile pahalı bir uygulama isteği farklı yerlerde başarısız olur. Web sınırındaki hız sınırlama, istek kalıplarını kısıtlamaya yardımcı olabilir; uygulama sınırları ise aramalar, yüklemeler veya dışa aktarmalar gibi işleri sınırlayabilir. NGINX'in istek sınırlama modülü bir mekanizma sağlar; anahtar ve eşikler gerçek kullanıcılara uygun olmalı ve meşru trafiği reddetmemek için test edilmelidir.
OWASP'nin hizmet reddi rehberi, uygulama davranışındaki kaynak tükenmesini de ele alır. Pahalı işlerin etrafına zaman ve boyut sınırları koyun, sınırlı kuyruklar kullanın ve hata sinyallerini izleyin. Yerel kontroller, zaten doymuş bir üst bağlantıda kapasite oluşturamaz. Seçilen teklife dahil olan belirli ağ korumasını doğrulayın ve bir yükseltme yolu hazırlayın. Bir kataloğun Katman 3–4 korumasının, her HTTP iş yükü için de koruma kanıtladığını asla varsaymayın.
Kurtarmayı yayının bir parçası haline getirin
Siteyi amaçlanan ana makine adını kullanarak harici bir istemciden kontrol edin. HTTPS, yönlendirmeleri, statik kaynakları, oturum açmaları ve temsili bir uygulama işlemini doğrulayın. Yönetim dinleyicilerinin ve özel dosyaların erişilemez kaldığını doğrulayın. Durdurulmuş bir üst kaynağı simüle edin ve sınırın iç ayrıntıları açığa çıkarmak veya sınırsız beklemek yerine kontrollü bir hata döndürdüğünü kontrol edin.
Canvas için barındırma hesabında mevcut olan kontrolleri okuyun. Bir VPS için web sınırını ve uygulamayı kendi işletim planınızın bir parçası olarak sürdürün. Büyük bir ağ bağlantı noktası bir kapasite spesifikasyonudur, uygulamanın bu verimi sürdürebileceğinin kanıtı değildir. İzleme, geri yükleme ve sağlayıcı kişilerini runbook'ta tutun. Yalnızca gerçek istek yolu ve pratik bir kurtarma yolu doğrulandıktan sonra yayınlayın.
Pratik kontrol listeniz.
- Genel ve yönetim isteğini izleyin.
- Sunulan kökleri ve üst dinleyicileri tanımlayın.
- İletilen başlıklara yalnızca onaylanmış aracılardan güvenin.
- Yetkilendirme ve önbellek sınırlarını test edin.
- Ağ ve uygulama hataları için sınırlar ve yükseltme hazırlayın.
Önemli olan ayrıntılar.
Bir web sunucusu aynı zamanda ters proxy olarak da işlev görebilir mi?+
Evet. NGINX belgelenmiş bir örnektir. Rolleri yapılandırmaya bağlıdır ve uygulamanın yine de kendi yetkilendirmesine ve bakımına ihtiyacı vardır.
Ters proxy kaynağı otomatik olarak gizler mi?+
Hayır. Yönlendirme, güvenlik duvarı ve dinleyici ayarları amaçlanan sınırı uygulamadıkça kaynak erişilebilir kalabilir.
İstek sınırlama her DDoS saldırısını durdurur mu?+
Hayır. Seçili HTTP istek kalıplarını ele alır. Ağ doygunluğu ve diğer kaynak hataları uygun üst kaynak ve uygulama kontrollerini gerektirir.
Kaynağa gidin.
Bu kaynaklar, bu kılavuzdaki teknik kavramları destekler. Bir üretim sistemini değiştirmeden önce güncel belgeleri izleyin.
- NGINX: Başlangıç kılavuzu nginx.org
- NGINX: HTTP istek sınırlama nginx.org
- NIST SP 800-207: Zero Trust Architecture nvlpubs.nist.gov
- OWASP: Hizmet Reddini Önleme cheatsheetseries.owasp.org
SwissOctet tarafından editoryal rehberlik. Örnekler açıklayıcıdır. Hizmet spesifikasyonları, mevcut seçenekler ve sözleşme koşulları ayrıca doğrulanmalıdır.