Erota HTTP-julkaisu sovelluksen suorituksesta ja pysyvistä tiedoista. Käänteinen välityspalvelin voi jäsentää reititystä ja rajoituksia, mutta alkuperän käyttöoikeus, sovelluksen valtuutus, ylävirran kapasiteetti ja palautuminen vaativat kukin omat hallintakeinonsa.
Verkkopyyntö ylittää useita vastuualueita
Verkkopalvelin vastaanottaa HTTP-pyyntöjä ja voi tarjoilla staattisia tiedostoja. Sovellusprosessi suorittaa projektin dynaamista toimintaa, kuten tilin tarkistamista tai tietokantakyselyä. Käänteinen välityspalvelin vastaanottaa pyyntöjä kyseisen prosessin puolesta ja välittää ne ylävirtaan. Yksi ohjelma voi täyttää useita rooleja, mutta vastuiden erottaminen helpottaa kokoonpanon ja palautumisen hahmottamista.
Jäljitä yksi pyyntö isäntänimen selvittämisestä vastaukseen. Kirjaa, mihin TLS päättyy, mikä prosessi valitsee reitin ja mikä komponentti voi lukea sovellustietoja. Tee sama ylläpitopyynnölle. Tämä harjoitus paljastaa usein kuuntelijan tai isäntänimen, joka luotiin testausta varten ja jäi vahingossa tavoitettavaksi. Kaavion tulisi kuvata käyttöön otettua polkua eikä arkkitehtuuria, jonka toivoit rakentavasi.
Käytä reunaa HTTP-toiminnan jäsentämiseen
NGINX dokumentoi sekä staattisen sisällön tarjoilun että pyyntöjen välittämisen ylävirtaan. Sen työntekijäarkkitehtuuri ja HTTP-moduulit tarjoavat kokoonpanomekanismeja, mutta tietty kokoonpano määrää silti toiminnan. Määritä isäntänimet, ylävirrat ja tiedostojärjestelmän juuret harkitusti. Rajoita tarjoiltavia tiedostoja, jotta kokoonpano, tunnistetiedot ja tietovaraston metatiedot eivät koskaan tule ladattaviksi siksi, että ne sattuvat sijaitsemaan sovelluksen lähellä.
Aseta sovelluksen mukaan sopivat rajat pyyntöjen runkojen koolle, aikakatkaisuille ja yhteyksille. Käsittele välimuisteja tiedostopäätöksenä: käyttäjään tai käyttöoikeuteen sidottu sisältö ei voi turvallisesti periä jaettua välimuistisääntöä ilman tarkistusta. Testaa todennus ja välimuistin toiminta yhdessä. Pidä kokoonpano toistettavana ja validoi muutokset ennen palvelun uudelleenlatausta, ja tunne reitti takaisin edelliseen toimivaan versioon.
| Kerros | Hyödyllinen vastuu | Tarkista ennen käyttöönottoa |
|---|---|---|
| Julkinen verkkoreuna | TLS, isäntänimireititys ja HTTP-rajoitukset | Varmenteet, juuret ja aiotut isäntänimet |
| Sovellusprosessi | Liiketoimintalogiikka ja valtuutus | Todennus, syötteiden tarkistukset ja riippuvuuksien viat |
| Sisäinen tietopalvelu | Sovelluksen pysyvä tila | Rajoitettu käyttöoikeus ja testattu palautus |
| Ylävirran tarjoajan verkko | Sopimuksen mukainen verkkopalvelu | Suojauksen laajuus ja eskalaatiopolku |
Käänteinen välityspalvelin ei poista alkuperän altistumista
Jos alkuperä pysyy julkisesti tavoitettavana, asiakasohjelma voi tavoittaa sen käyttämättä aiottua välityspalvelureittiä. Rajoita alkuperän käyttöoikeutta verkkosuunnittelun ja sovelluksen kokoonpanon avulla, kun käyttöönotto edellyttää kyseistä rajaa. Yhdellä koneella taustajärjestelmä voi usein kuunnella paikallista silmukkaa tai paikallista pistoketta. Koneiden välillä käytä nimenomaisesti rajoitettuja reittejä ja sopivaa suojausta ylävirran yhteydelle.
Myös välitetyt otsikot tarvitsevat luottamussäännön. Hyväksy tiedot alkuperäisestä asiakkaasta vain luotetuilta välittäjiltä ja estä mielivaltaisia kutsujia toimittamasta arvoja, joita sovellus pitää auktoritatiivisina. Päätä, mitä käyttölokeihin ja virheraportteihin tulee. Välityspalvelin voi muuttaa kullakin kerroksella käytettävissä olevia tietoja; se ei poista tilin tunnisteita eikä tee sovelluksesta anonyymiä sen omalle operaattorille.
Tee käyttöoikeuspäätökset sovelluksen sisällä
NIST:n Zero Trust -arkkitehtuuri keskittyy resurssien käyttöoikeuspäätöksiin eikä pelkkään verkkoasemaan perustuvaan implisiittiseen luottamukseen. Sovella tätä periaatetta konkreettisesti: todenna kutsuja, valtuuta pyydetty toiminto ja anna palvelutileille vain niiden tarvitsema laajuus. Sisäisestä aliverkosta saapuvasta pyynnöstä ei pitäisi automaattisesti tulla järjestelmänvalvojan pyyntöä.
Erota julkiset ja hallinnolliset toiminnot, kun se on käytännöllistä. Tarkista käyttöoikeus uudelleen, kun käyttäjä käyttää tietuetta, sen sijaan että luottaisit vain alkuperäiseen kirjautumiseen. Pidä välityspalvelimen, sovelluksen ja tietokannan tunnistetiedot erillään. Ota muutokset käyttöön vaiheittain, jotta ne voidaan testata, alkaen kapeasta arkaluonteisesta polusta. Käyttöönoton kutsuminen Zero Trustiksi on vähemmän hyödyllistä kuin sen osoittaminen, että kielletty toiminto todella estetään siitä vastaavassa komponentissa.
Suunnittele palvelunestosuojaus useammalle kuin yhdelle kerrokselle
Kyllästynyt verkkoyhteys ja raskas sovelluspyyntö epäonnistuvat eri paikoissa. Nopeusrajoitus verkkoreunalla voi auttaa rajoittamaan pyyntömalleja, kun taas sovellusrajoitukset voivat rajata työtä, kuten hakuja, latauksia tai vientitoimintoja. NGINX:n pyyntörajoitusmoduuli tarjoaa yhden mekanismin; avaimen ja kynnysarvojen on sovittava todellisille käyttäjille, ja ne on testattava, jotta ei hylätä kelvollista liikennettä.
OWASP:n palvelunestosuositus käsittelee myös resurssien loppumista sovelluksen toiminnassa. Aseta aika- ja kokorajoituksia raskaalle työlle, käytä rajattuja jonoja ja seuraa vikasignaaleja. Paikalliset hallintakeinot eivät voi luoda kapasiteettia ylävirran yhteyteen, joka on jo kyllästynyt. Vahvista valittuun tarjoukseen sisältyvä erityinen verkkosuojaus ja valmistele eskalaatiopolku. Älä koskaan oleta, että luettelon kerroksen 3–4 suojaus todistaisi myös suojauksen jokaiselle HTTP-työkuormalle.
Tee palautumisesta osa julkaisua
Tarkista sivusto ulkoisesta asiakasohjelmasta sen aiottua isäntänimeä käyttäen. Vahvista HTTPS, uudelleenohjaukset, staattiset resurssit, kirjautumiset ja edustava sovellustapahtuma. Varmista, että hallinnolliset kuuntelijat ja yksityiset tiedostot pysyvät tavoittamattomina. Simuloi pysäytettyä ylävirtaa ja tarkista, että reuna palauttaa hallitun virheen sen sijaan, että paljastaisi sisäisiä tietoja tai odottaisi ilman rajaa.
Lue Canvasin osalta isännöintitilissä käytettävissä olevat hallintakeinot. Jos kyseessä on VPS, ylläpidä verkkoreunaa ja sovellusta osana omaa toimintasuunnitelmaasi. Suuri verkkoportti on kapasiteettimäärittely, ei todiste siitä, että sovellus pystyy ylläpitämään kyseistä läpäisyä. Pidä seuranta, palautus ja tarjoajan yhteystiedot käyttöohjeessa. Julkaise vasta, kun todellinen pyyntöpolku ja käytännöllinen palautumispolku on vahvistettu.
Käytännön tarkistuslistasi.
- Jäljitä julkinen ja hallinnollinen pyyntö.
- Määritä tarjoiltavat juuret ja ylävirran kuuntelijat.
- Luota välitettyihin otsikoihin vain hyväksytyiltä välittäjiltä.
- Testaa valtuutus ja välimuistin rajat.
- Valmistele rajoitukset ja eskalaatio verkko- ja sovellusvikojen varalle.
Olennaiset yksityiskohdat.
Voiko verkkopalvelin toimia myös käänteisenä välityspalvelimena?+
Kyllä. NGINX on yksi dokumentoitu esimerkki. Sen roolit riippuvat kokoonpanosta, ja sovellus tarvitsee silti oman valtuutuksensa ja ylläpitonsa.
Piilottaako käänteinen välityspalvelin alkuperän automaattisesti?+
Ei. Alkuperä voi pysyä tavoitettavana, elleivät reititys-, palomuuri- ja kuuntelija-asetukset valvo aiottua rajaa.
Pysäyttääkö pyyntöjen rajoittaminen kaikki DDoS-hyökkäykset?+
Ei. Se käsittelee valittuja HTTP-pyyntömalleja. Verkon kyllästyminen ja muut resurssiviat vaativat asianmukaiset ylävirran ja sovelluksen hallintakeinot.
Mene lähteelle.
Nämä lähteet tukevat tämän oppaan teknisiä käsitteitä. Noudata ajantasaisia dokumentaatioita ennen tuotantojärjestelmän muuttamista.
- NGINX: Aloittelijan opas nginx.org
- NGINX: HTTP-pyyntöjen rajoittaminen nginx.org
- NIST SP 800-207: Zero Trust -arkkitehtuuri nvlpubs.nist.gov
- OWASP: Palveluneston estäminen cheatsheetseries.owasp.org
Toimituksellinen ohjaus: SwissOctet. Esimerkit ovat havainnollistavia. Palvelumääritykset, saatavilla olevat vaihtoehdot ja sopimusehdot on tarkistettava erikseen.