Válassza külön a HTTP közzétételt az alkalmazás végrehajtásától és az állandó adatoktól. A fordított proxy rendszerezheti az útvonalválasztást és a korlátokat, de az eredet elérése, az alkalmazás engedélyezése, a felsőbb szintű kapacitás és a helyreállítás külön-külön vezérlést igényel.
Egy webes kérés több felelősségi kört érint
A webkiszolgáló HTTP kéréseket fogad, és statikus fájlokat szolgálhat ki. Az alkalmazásfolyamat a projekt dinamikus viselkedését hajtja végre, például fiókot ellenőriz vagy adatbázist kérdez le. A fordított proxy e folyamat nevében fogadja a kéréseket, és továbbítja azokat egy felsőbb szintű kiszolgálónak. Egy program több szerepet is betölthet, de a felelősségek szétválasztása megkönnyíti a konfiguráció és a helyreállítás átgondolását.
Kövessen végig egy kérést a hosztnév feloldásától a válaszig. Jegyezze fel, hol végződik a TLS, melyik folyamat választja ki az útvonalat, és melyik összetevő olvashat alkalmazásadatokat. Tegye ugyanezt egy adminisztratív kéréssel. Ez a gyakorlat gyakran felfedi azt a figyelőt vagy hosztnevet, amelyet teszteléshez hoztak létre, és véletlenül elérhető maradt. A diagramnak a telepített útvonalat kell leírnia, nem pedig azt az architektúrát, amelyet meg szeretett volna építeni.
A perem használata a HTTP viselkedés rendszerezésére
Az NGINX dokumentálja a statikus tartalom kiszolgálását és a kérések felsőbb szintű kiszolgálóhoz való továbbítását is. Munkásarchitektúrája és HTTP moduljai konfigurációs mechanizmusokat biztosítanak, de a viselkedést továbbra is egy adott konfiguráció határozza meg. Szándékosan határozza meg a hosztneveket, a felsőbb szintű kiszolgálókat és a fájlrendszer gyökereit. Korlátozza a kiszolgálható fájlokat, hogy a konfiguráció, a hitelesítő adatok és a tároló metaadatai soha ne váljanak letölthetővé csak azért, mert véletlenül az alkalmazás közelében találhatók.
Az alkalmazásnak megfelelő korlátokat állítson be a kérés törzsére, az időtúllépésekre és a kapcsolatokra. A gyorsítótárakat adatkezelési döntésként kezelje: a felhasználóhoz vagy jogosultsághoz kötött tartalom nem örökölhet biztonságosan egy megosztott gyorsítótárazási szabályt felülvizsgálat nélkül. Tesztelje együtt a hitelesítést és a gyorsítótár viselkedését. Tartson fenn reprodukálható konfigurációt, és a szolgáltatás újratöltése előtt érvényesítse a változtatásokat, ismert visszaúttal az előző működő verzióhoz.
| Réteg | Hasznos felelősség | Ellenőrzés indítás előtt |
|---|---|---|
| Nyilvános webes perem | TLS, hosztnév-alapú útvonalválasztás és HTTP korlátok | Tanúsítványok, gyökerek és szándékolt hosztnevek |
| Alkalmazásfolyamat | Üzleti logika és engedélyezés | Hitelesítés, bemenetellenőrzés és függőségi hiba |
| Belső adatszolgáltatás | Állandó alkalmazásállapot | Korlátozott hozzáférés és tesztelt helyreállítás |
| Felsőbb szintű szolgáltatói hálózat | A szerződött hálózati szolgáltatás | Védelmi hatókör és eszkalációs útvonal |
A fordított proxy nem szünteti meg az eredet kiszolgáltatottságát
Ha az eredet nyilvánosan elérhető marad, az ügyfél a szándékolt proxyútvonal használata nélkül is elérheti. Ha a telepítés megköveteli ezt a határt, korlátozza az eredet elérését a hálózati kialakítással és az alkalmazáskonfigurációval. Egy gépen a háttérrendszer gyakran figyelhet a loopback interfészen vagy egy helyi socketen. Gépek között használjon kifejezetten korlátozott útvonalakat és megfelelő védelmet a felsőbb szintű kapcsolat számára.
A továbbított fejlécekhez is szükség van bizalmi szabályra. Az eredeti ügyfélre vonatkozó információkat csak megbízható közvetítőktől fogadja el, és akadályozza meg, hogy tetszőleges hívók olyan értékeket adjanak meg, amelyeket az alkalmazás hitelesnek tekint. Döntse el, mi jelenjen meg a hozzáférési naplókban és a hibaüzenetekben. A proxy megváltoztathatja az egyes szinteken elérhető információkat; nem törli a fiókazonosítókat, és nem teszi az alkalmazást névtelenné a saját üzemeltetője számára.
Hozzáférési döntések alkalmazása az alkalmazáson belül
A NIST nulla bizalmon alapuló architektúrája az erőforrásokhoz való hozzáférési döntésekre összpontosít, nem pedig a kizárólag hálózati helyzeten alapuló hallgatólagos bizalomra. Alkalmazza ezt az elvet konkrétan: hitelesítse a hívót, engedélyezze a kért műveletet, és a szolgáltatásfiókoknak csak a szükséges hatókört adja meg. Egy belső alhálózatról érkező kérés nem válhat automatikusan rendszergazdai kéréssé.
Ahol gyakorlatias, válassza külön a nyilvános és az adminisztratív funkciókat. Amikor egy felhasználó hozzáfér egy rekordhoz, ellenőrizze újra a jogosultságot, ne csak a kezdeti bejelentkezésre támaszkodjon. A proxy, az alkalmazás és az adatbázis hitelesítő adatai maradjanak különállók. A változtatásokat tesztelhető szakaszokban vezesse be, egy szűk, érzékeny útvonallal kezdve. Egy telepítést nulla bizalomnak nevezni kevésbé hasznos, mint bebizonyítani, hogy egy tiltott műveletet valóban megtagad a felelős összetevő.
A szolgáltatásmegtagadás tervezése több szinten
A telített hálózati kapcsolat és a költséges alkalmazáskérés különböző helyeken hibázik. A webes peremen alkalmazott sebességkorlátozás segíthet a kérésminták szűkítésében, míg az alkalmazáskorlátok behatárolhatják az olyan munkát, mint a keresések, feltöltések vagy exportálások. Az NGINX kéréskorlátozó modulja egy mechanizmust biztosít; a kulcsnak és a küszöbértékeknek a valós felhasználókhoz kell illeszkedniük, és tesztelni kell őket, hogy elkerüljük a jogos forgalom elutasítását.
Az OWASP szolgáltatásmegtagadásra vonatkozó útmutatása az alkalmazás viselkedésében fellépő erőforrás-kimerüléssel is foglalkozik. A költséges munkák köré állítson idő- és méretkorlátokat, használjon korlátozott sorokat, és figyelje a hiba jeleit. A helyi vezérlők nem tudnak kapacitást teremteni egy már telített felsőbb szintű kapcsolatban. Erősítse meg a választott ajánlatban szereplő konkrét hálózatvédelmet, és készítsen eszkalációs útvonalat. Soha ne feltételezze, hogy egy katalógus 3–4 rétegű védelme egyben minden HTTP munkaterhelés védelmét is bizonyítja.
A helyreállítás legyen a közzététel része
Ellenőrizze a webhelyet egy külső ügyfélről, a szándékolt hosztnevét használva. Ellenőrizze a HTTPS-t, az átirányításokat, a statikus erőforrásokat, a bejelentkezéseket és egy reprezentatív alkalmazástranzakciót. Győződjön meg arról, hogy az adminisztratív figyelők és a privát fájlok továbbra sem érhetők el. Szimuláljon egy leállt felsőbb szintű kiszolgálót, és ellenőrizze, hogy a perem szabályozott hibát ad vissza, nem pedig belső részleteket tár fel vagy korlát nélkül vár.
A Canvas esetében olvassa el a tárhelyfiókon belül elérhető vezérlőket. Egy VPS esetében a webes peremet és az alkalmazást a saját üzemeltetési tervének részeként tartsa fenn. A nagy hálózati port kapacitásadat, nem pedig annak bizonyítéka, hogy az alkalmazás képes fenntartani azt az átviteli sebességet. A figyelést, a helyreállítást és a szolgáltatói elérhetőségeket tartsa a üzemeltetési kézikönyvben. Csak a tényleges kérési útvonal és egy gyakorlatias helyreállítási útvonal ellenőrzése után tegyen közzé.
Az Ön gyakorlati ellenőrzőlistája.
- Kövessen végig egy nyilvános és egy adminisztratív kérést.
- Határozza meg a kiszolgált gyökereket és a felsőbb szintű figyelőket.
- A továbbított fejlécekben csak jóváhagyott közvetítőknek bízzon.
- Tesztelje az engedélyezési és gyorsítótárazási határokat.
- Készítsen korlátokat és eszkalációt hálózati és alkalmazáshibák esetére.
A fontos részletek.
Működhet a webkiszolgáló fordított proxyként is?+
Igen. Az NGINX egy dokumentált példa. Szerepei a konfigurációtól függenek, és az alkalmazásnak továbbra is szüksége van saját engedélyezésre és karbantartásra.
A fordított proxy automatikusan elrejti az eredetet?+
Nem. Az eredet elérhető maradhat, hacsak az útvonalválasztás, a tűzfal és a figyelő beállításai nem érvényesítik a szándékolt határt.
A kéréskorlátozás megállít minden DDoS támadást?+
Nem. Kiválasztott HTTP kérésmintákkal foglalkozik. A hálózati telítettség és más erőforráshibák megfelelő felsőbb szintű és alkalmazásvezérlést igényelnek.
Menjen a forráshoz.
Ezek a hivatkozások támogatják az útmutató műszaki fogalmait. Kövesse az aktuális dokumentációt, mielőtt éles rendszert módosítana.
- NGINX: Kezdőknek szóló útmutató nginx.org
- NGINX: HTTP kéréskorlátozás nginx.org
- NIST SP 800-207: Nulla bizalmon alapuló architektúra nvlpubs.nist.gov
- OWASP: Szolgáltatásmegtagadás megelőzése cheatsheetseries.owasp.org
Szerkesztői útmutatás: SwissOctet. A példák tájékoztató jellegűek. A szolgáltatási specifikációkat, az elérhető opciókat és a szerződéses feltételeket külön kell ellenőrizni.