# Oddělte veřejné webové rozhraní od aplikace | SwissOctet Insights https://swissoctet.com/cs/insights/separate-the-web-edge-from-the-app/ SwissOctet / Přehledy / Web a onion Web a onion Aplikované · 4 min čtení Oddělte veřejnou webovou hranu od aplikace Dejte webovému serveru, reverzní proxy a aplikaci odlišné odpovědnosti, se záměrným přístupem k originu, TLS, limity požadavků a cestou pro incidenty. Od SwissOctet Editorial Uložit průvodce Kopírovat odkaz NA TÉTO STRÁNCE 01 Webový požadavek prochází několika odpovědnostmi 02 Použijte rozhraní k uspořádání chování HTTP 03 Reverzní proxy neodstraňuje vystavení původního serveru 04 Rozhodnutí o přístupu uplatňujte uvnitř aplikace 05 Odmítnutí služby plánujte ve více než jedné vrstvě 06 Začleňte obnovu do publikace Váš praktický kontrolní seznam Zdroje a další čtení Zpět do knihovny PŘÍMÁ ODPOVĚĎ Oddělte publikaci HTTP od spouštění aplikace a trvalých dat. Reverzní proxy může uspořádat směrování a limity, ale přístup k původnímu serveru, autorizace aplikace, kapacita upstreamu a obnova vyžadují každý vlastní kontroly. 01 Webový požadavek prochází několika odpovědnostmi Webový server přijímá požadavky HTTP a může poskytovat statické soubory. Proces aplikace vykonává dynamické chování projektu, jako je kontrola účtu nebo dotaz do databáze. Reverzní proxy přijímá požadavky jménem tohoto procesu a předává je upstreamu. Jeden program může plnit několik rolí, ale oddělení odpovědností usnadňuje uvažování o konfiguraci a obnově. Sledujte jeden požadavek od překladu názvu hostitele až po odpověď. Zaznamenejte, kde končí TLS, který proces volí trasu a která komponenta může číst data aplikace. Totéž proveďte pro administrativní požadavek. Toto cvičení často odhalí naslouchající prvek nebo název hostitele, který byl vytvořen pro testování a omylem zůstal dostupný. Diagram by měl popisovat nasazenou cestu, nikoli architekturu, kterou jste doufali vytvořit. 02 Použijte rozhraní k uspořádání chování HTTP NGINX dokumentuje jak poskytování statického obsahu, tak předávání požadavků upstreamu. Jeho architektura workerů a moduly HTTP poskytují konfigurační mechanismy, ale konkrétní konfigurace stále určuje chování. Definujte názvy hostitelů, upstreamy a kořeny souborového systému záměrně. Omezte soubory, které lze poskytovat, aby se konfigurace, přihlašovací údaje a metadata repozitáře nikdy nestaly stahovatelnými jen proto, že se nacházejí poblíž aplikace. Nastavte vhodné limity pro těla požadavků, časové limity a připojení podle aplikace. S cache zacházejte jako s datovým rozhodnutím: obsah vázaný na uživatele nebo oprávnění nemůže bezpečně převzít sdílené pravidlo ukládání do cache bez kontroly. Testujte autentizaci a chování cache společně. Uchovávejte reprodukovatelnou konfiguraci a před opětovným načtením služby ověřte změny, se známou cestou zpět k předchozí funkční verzi. Vrstva Užitečná odpovědnost Zkontrolujte před spuštěním Veřejné webové rozhraní Směrování podle názvu hostitele TLS a limity HTTP Certifikáty, kořeny a zamýšlené názvy hostitelů Proces aplikace Obchodní logika a autorizace Autentizace, kontroly vstupů a selhání závislostí Interní datová služba Trvalý stav aplikace Omezený přístup a otestované obnovení Síť poskytovatele upstreamu Smluvně zajištěná síťová služba Rozsah ochrany a cesta eskalace 03 Reverzní proxy neodstraňuje vystavení původního serveru Pokud původní server zůstane veřejně dostupný, klient se k němu může dostat bez použití zamýšlené cesty přes proxy. Omezte přístup k původnímu serveru prostřednictvím návrhu sítě a konfigurace aplikace, pokud nasazení takovou hranici vyžaduje. Na jednom stroji může backend často naslouchat na loopbacku nebo místním socketu. Napříč stroji použijte explicitní omezené trasy a vhodnou ochranu upstreamového připojení. Předávané hlavičky také potřebují pravidlo důvěryhodnosti. Informace o původním klientovi přijímejte pouze od důvěryhodných prostředníků a zabraňte libovolným volajícím dodávat hodnoty, které aplikace považuje za směrodatné. Rozhodněte, co se objeví v přístupových protokolech a chybových zprávách. Proxy může změnit informace dostupné v každé vrstvě; nevymaže však identifikátory účtů ani neučiní aplikaci anonymní vůči jejímu vlastnímu provozovateli. 04 Rozhodnutí o přístupu uplatňujte uvnitř aplikace Architektura Zero Trust podle NIST se zaměřuje na rozhodnutí o přístupu k prostředkům, nikoli na implicitní důvěru založenou pouze na síťovém umístění. Tento princip uplatněte konkrétně: autentizujte volajícího, autorizujte požadovanou operaci a přidělte servisním účtům pouze jejich požadovaný rozsah. Požadavek přicházející z interní podsítě by se neměl automaticky stát administrativním požadavkem. Pokud je to praktické, oddělte veřejné a administrativní funkce. Při přístupu uživatele k záznamu znovu zkontrolujte oprávnění, místo abyste se spoléhali pouze na počáteční přihlášení. Udržujte přihlašovací údaje pro proxy, aplikaci a databázi oddělené. Zavádějte změny v etapách, které lze testovat, počínaje úzkou citlivou cestou. Nazývat nasazení Zero Trust je méně užitečné než prokázat, že zakázaná akce je skutečně odmítnuta v komponentě, která za ni odpovídá. 05 Odmítnutí služby plánujte ve více než jedné vrstvě Nasycené síťové spojení a náročný požadavek aplikace selhávají na různých místech. Omezování rychlosti na webovém rozhraní může pomoci omezit vzorce požadavků, zatímco limity aplikace mohou ohraničit práci, jako jsou vyhledávání, nahrávání nebo exporty. Modul pro omezení požadavků v NGINX poskytuje jeden mechanismus; klíč a prahové hodnoty musí odpovídat skutečným uživatelům a musí být otestovány, aby nedocházelo k odmítání legitimního provozu. Pokyny OWASP pro odmítnutí služby se také zabývají vyčerpáním prostředků v chování aplikace. Stanovte časové a velikostní limity pro náročnou práci, používejte omezené fronty a sledujte signály selhání. Místní kontroly nemohou vytvořit kapacitu v upstreamovém spojení, které je již nasycené. Ověřte konkrétní síťovou ochranu zahrnutou ve zvolené nabídce a připravte cestu eskalace. Nikdy nepředpokládejte, že ochrana vrstvy 3–4 uvedená v katalogu také prokazuje ochranu pro každou úlohu HTTP. 06 Začleňte obnovu do publikace Zkontrolujte web z externího klienta pomocí jeho zamýšleného názvu hostitele. Ověřte HTTPS, přesměrování, statické prostředky, přihlášení a reprezentativní transakci aplikace. Potvrďte, že administrativní naslouchající prvky a soukromé soubory zůstávají nedostupné. Simulujte zastavený upstream a zkontrolujte, že rozhraní vrací řízené selhání, místo aby odhalilo interní podrobnosti nebo čekalo bez limitu. Pro Canvas si přečtěte ovládací prvky dostupné v rámci hostitelského účtu. Pro VPS udržujte webové rozhraní a aplikaci jako součást vlastního provozního plánu. Velký síťový port je specifikace kapacity, nikoli důkaz, že aplikace dokáže tento výkon udržet. Udržujte monitorování, obnovu a kontakty na poskytovatele v runbooku. Publikujte až poté, co byla ověřena skutečná cesta požadavku a praktická cesta obnovy. PŘEVEĎTE TO V AKCI Váš praktický kontrolní seznam. ✓ Sledujte veřejný a administrativní požadavek. ✓ Definujte poskytované kořeny a upstreamové naslouchající prvky. ✓ Předávaným hlavičkám důvěřujte pouze od schválených prostředníků. ✓ Otestujte autorizaci a hranice cache. ✓ Připravte limity a eskalaci pro selhání sítě a aplikace. Stáhnout kontrolní seznam ČASTÉ OTÁZKY Podrobnosti, na kterých záleží. Může webový server fungovat také jako reverzní proxy? + Ano. NGINX je jeden zdokumentovaný příklad. Jeho role závisí na konfiguraci a aplikace stále potřebuje vlastní autorizaci a údržbu. Skryje reverzní proxy automaticky původní server? + Ne. Původní server může zůstat dostupný, pokud směrování, firewall a nastavení naslouchajících prvků nevynutí zamýšlenou hranici. Zastaví omezení požadavků každý útok DDoS? + Ne. Řeší vybrané vzorce požadavků HTTP. Nasycení sítě a další selhání prostředků vyžadují vhodné kontroly upstreamu a aplikace. PRIMÁRNÍ ZDROJE Jděte ke zdroji. Tyto zdroje podporují technické koncepty v tomto průvodci. Před změnou produkčního systému se řiďte aktuální dokumentací. NGINX: Příručka pro začátečníky nginx.org NGINX: Omezení požadavků HTTP nginx.org NIST SP 800-207: Architektura Zero Trust nvlpubs.nist.gov OWASP: Prevence odmítnutí služby cheatsheetseries.owasp.org Redakční vedení od SwissOctet. Příklady jsou ilustrativní. Specifikace služeb, dostupné možnosti a smluvní podmínky je nutné ověřit samostatně. PROPOJTE ZNALOSTI Související infrastruktura. Canvas Web Švýcarsko Vector VPS Švýcarsko Pulse NVMe Švýcarsko Transit 40 Švýcarsko UDRŽTE NIT Vaše další terénní poznámky. Prozkoumat všechny průvodce TERÉNNÍ POZNÁMKA / 01 + Provoz druhého dne Aplikované Základ pro zpevnění Linux VPS, který můžete udržovat Zabezpečte správu, vystavte pouze nezbytné služby a zaveďte aktualizace a obnovu, aniž byste se uzamkli. 6 min čtení Přečtěte si průvodce TERÉNNÍ POZNÁMKA / 02 + Web a onion Základ Webhosting nebo VPS: zvolte práci, kterou chcete vlastnit Porovnejte požadavky aplikace, kontrolu a odpovědnosti za údržbu, místo abyste VPS považovali za automatický další krok pro každý web. 6 min čtení Přečtěte si průvodce TERÉNNÍ POZNÁMKA / 03 + Web a onion Aplikované Runbook přepnutí domény, DNS a TLS na nový server Připravte společně směrování hostname, certifikáty a rollback, aby migrace změnila server, aniž by narušila identitu webu nebo zabezpečená připojení. 4 min čtení Přečtěte si průvodce