# Oddziel publiczną krawędź sieciową od aplikacji | SwissOctet Insights https://swissoctet.com/pl/insights/separate-the-web-edge-from-the-app/ SwissOctet / Spostrzeżenia / Web i onion Web i onion Praktyczne · 4 min czytania Oddziel publiczną warstwę webową od aplikacji Nadaj serwerowi webowemu, odwrotnemu proxy i aplikacji odrębne obowiązki, z zamierzonym dostępem do źródła, TLS, limitami żądań i ścieżką postępowania w incydencie. Autor: SwissOctet Editorial Zapisz przewodnik Kopiuj link NA TEJ STRONIE 01 Żądanie sieciowe przechodzi przez kilka zakresów odpowiedzialności 02 Użyj krawędzi do uporządkowania zachowania HTTP 03 Odwrotne proxy nie usuwa ekspozycji źródła 04 Stosuj decyzje o dostępie wewnątrz aplikacji 05 Zaplanuj odmowę usługi na więcej niż jednej warstwie 06 Uczyń odzyskiwanie częścią publikacji Twoja praktyczna lista kontrolna Źródła i dalsza lektura Powrót do biblioteki BEZPOŚREDNIA ODPOWIEDŹ Oddziel publikację HTTP od wykonywania aplikacji i trwałych danych. Odwrotne proxy może uporządkować routing i limity, ale dostęp do źródła, autoryzacja aplikacji, przepustowość nadrzędna i odzyskiwanie wymagają własnych kontroli. 01 Żądanie sieciowe przechodzi przez kilka zakresów odpowiedzialności Serwer sieciowy odbiera żądania HTTP i może obsługiwać pliki statyczne. Proces aplikacji wykonuje dynamiczne zachowanie projektu, takie jak sprawdzanie konta lub odpytywanie bazy danych. Odwrotne proxy odbiera żądania w imieniu tego procesu i przekazuje je do nadrzędnego. Jeden program może pełnić kilka ról, ale rozdzielenie odpowiedzialności ułatwia rozumowanie o konfiguracji i odzyskiwaniu. Prześledź jedno żądanie od rozwiązania nazwy hosta do odpowiedzi. Zapisz, gdzie kończy się TLS, który proces wybiera trasę i który składnik może odczytywać dane aplikacji. Zrób to samo dla żądania administracyjnego. To ćwiczenie często ujawnia nasłuch lub nazwę hosta utworzone do testów, które przypadkowo pozostały osiągalne. Diagram powinien opisywać wdrożoną ścieżkę, a nie architekturę, którą miałeś nadzieję zbudować. 02 Użyj krawędzi do uporządkowania zachowania HTTP NGINX dokumentuje zarówno obsługę treści statycznych, jak i przekazywanie żądań do serwera nadrzędnego. Jego architektura procesów roboczych i moduły HTTP zapewniają mechanizmy konfiguracji, ale konkretna konfiguracja nadal określa zachowanie. Zdefiniuj nazwy hostów, serwery nadrzędne i katalogi główne systemu plików celowo. Ogranicz pliki, które mogą być obsługiwane, aby konfiguracja, poświadczenia i metadane repozytorium nigdy nie stały się możliwe do pobrania tylko dlatego, że znajdują się blisko aplikacji. Ustaw odpowiednie limity dla treści żądań, limitów czasu i połączeń zgodnie z aplikacją. Traktuj pamięci podręczne jako decyzję o danych: treść powiązana z użytkownikiem lub uprawnieniem nie może bezpiecznie dziedziczyć współdzielonej reguły buforowania bez przeglądu. Testuj uwierzytelnianie i zachowanie pamięci podręcznej razem. Utrzymuj odtwarzalną konfigurację i waliduj zmiany przed ponownym załadowaniem usługi, ze znaną drogą powrotu do poprzedniej działającej wersji. Warstwa Użyteczna odpowiedzialność Sprawdź przed uruchomieniem Publiczna krawędź sieciowa TLS, routing nazw hostów i limity HTTP Certyfikaty, katalogi główne i zamierzone nazwy hostów Proces aplikacji Logika biznesowa i autoryzacja Uwierzytelnianie, sprawdzanie danych wejściowych i awaria zależności Wewnętrzna usługa danych Trwały stan aplikacji Ograniczony dostęp i przetestowane przywracanie Sieć dostawcy nadrzędnego Umowna usługa sieciowa Zakres ochrony i ścieżka eskalacji 03 Odwrotne proxy nie usuwa ekspozycji źródła Jeśli źródło pozostaje publicznie dostępne, klient może do niego dotrzeć bez użycia zamierzonej trasy proxy. Ogranicz dostęp do źródła przez projekt sieci i konfigurację aplikacji, gdy wdrożenie wymaga tej granicy. Na jednej maszynie backend często może nasłuchiwać na interfejsie loopback lub lokalnym gnieździe. Między maszynami użyj jawnych ograniczonych tras i odpowiedniej ochrony połączenia z serwerem nadrzędnym. Nagłówki przekazywane również wymagają reguły zaufania. Akceptuj informacje o oryginalnym kliencie tylko od zaufanych pośredników i uniemożliwiaj dowolnym wywołującym dostarczanie wartości, które aplikacja traktuje jako autorytatywne. Zdecyduj, co pojawia się w dziennikach dostępu i raportach błędów. Proxy może zmieniać informacje dostępne na każdej warstwie; nie usuwa identyfikatorów kont ani nie czyni aplikacji anonimową dla jej własnego operatora. 04 Stosuj decyzje o dostępie wewnątrz aplikacji Architektura Zero Trust NIST koncentruje się na decyzjach o dostępie do zasobów, a nie na domyślnym zaufaniu opartym wyłącznie na lokalizacji sieciowej. Zastosuj tę zasadę konkretnie: uwierzytelnij wywołującego, autoryzuj żądaną operację i przyznaj kontom usług tylko wymagany zakres. Żądanie przychodzące z podsieci wewnętrznej nie powinno automatycznie stawać się żądaniem administratora. Rozdziel funkcje publiczne i administracyjne tam, gdzie to praktyczne. Sprawdzaj ponownie uprawnienia, gdy użytkownik uzyskuje dostęp do rekordu, zamiast polegać wyłącznie na początkowym logowaniu. Utrzymuj odrębne poświadczenia dla proxy, aplikacji i bazy danych. Wprowadzaj zmiany etapami, które można testować, zaczynając od wąskiej, wrażliwej ścieżki. Nazywanie wdrożenia Zero Trust jest mniej użyteczne niż wykazanie, że zabroniona akcja jest faktycznie odrzucana w komponencie za nią odpowiedzialnym. 05 Zaplanuj odmowę usługi na więcej niż jednej warstwie Zatłoczone łącze sieciowe i kosztowne żądanie aplikacji zawodzą w różnych miejscach. Ograniczanie tempa na brzegu sieci web może pomóc ograniczyć wzorce żądań, natomiast limity aplikacji mogą ograniczać pracę, taką jak wyszukiwania, przesyłanie plików czy eksporty. Moduł ograniczania żądań NGINX zapewnia jeden mechanizm; klucz i progi muszą pasować do rzeczywistych użytkowników i być przetestowane, aby uniknąć odrzucania legalnego ruchu. Wytyczne OWASP dotyczące ataków typu denial-of-service odnoszą się również do wyczerpywania zasobów w zachowaniu aplikacji. Ustal limity czasu i rozmiaru wokół kosztownej pracy, używaj ograniczonych kolejek i monitoruj sygnały awarii. Lokalne mechanizmy kontroli nie mogą stworzyć przepustowości w już zatłoczonym łączu nadrzędnym. Potwierdź konkretną ochronę sieciową zawartą w wybranej ofercie i przygotuj ścieżkę eskalacji. Nigdy nie zakładaj, że ochrona warstwy 3–4 w katalogu dowodzi również ochrony każdego obciążenia HTTP. 06 Uczyń odzyskiwanie częścią publikacji Sprawdź witrynę z zewnętrznego klienta, używając jej docelowej nazwy hosta. Zweryfikuj HTTPS, przekierowania, zasoby statyczne, logowania i reprezentatywną transakcję aplikacji. Potwierdź, że nasłuchy administracyjne i pliki prywatne pozostają niedostępne. Zasymuluj zatrzymany serwer nadrzędny i sprawdź, czy brzeg zwraca kontrolowaną awarię, zamiast ujawniać wewnętrzne szczegóły lub czekać bez limitu. W przypadku Canvas przeczytaj mechanizmy kontroli dostępne w ramach konta hostingowego. W przypadku VPS utrzymuj brzeg sieci web i aplikację jako część własnego planu operacyjnego. Duży port sieciowy to specyfikacja przepustowości, a nie dowód, że aplikacja może utrzymać taką przepustowość. Utrzymuj monitorowanie, przywracanie i kontakty do dostawcy w runbooku. Publikuj dopiero po zweryfikowaniu rzeczywistej ścieżki żądań i praktycznej ścieżki odzyskiwania. ZAMIEŃ TO W DZIAŁANIE Twoja praktyczna lista kontrolna. ✓ Prześledź żądanie publiczne i administracyjne. ✓ Zdefiniuj obsługiwane katalogi główne i nasłuchy serwerów nadrzędnych. ✓ Ufaj nagłówkom przekazywanym wyłącznie od zatwierdzonych pośredników. ✓ Przetestuj autoryzację i granice pamięci podręcznej. ✓ Przygotuj limity i eskalację dla awarii sieci i aplikacji. Pobierz listę kontrolną CZĘSTE PYTANIA Szczegóły, które mają znaczenie. Czy serwer web może również działać jako reverse proxy? + Tak. NGINX jest jednym z udokumentowanych przykładów. Jego role zależą od konfiguracji, a aplikacja nadal wymaga własnej autoryzacji i konserwacji. Czy reverse proxy automatycznie ukrywa serwer źródłowy? + Nie. Serwer źródłowy może pozostać osiągalny, o ile routing, zapora i ustawienia nasłuchu nie wymuszą zamierzonej granicy. Czy ograniczanie żądań zatrzyma każdy atak DDoS? + Nie. Odnosi się do wybranych wzorców żądań HTTP. Zatłoczenie sieci i inne awarie zasobów wymagają odpowiednich mechanizmów kontroli nadrzędnych i aplikacyjnych. GŁÓWNE ŹRÓDŁA Przejdź do źródła. Te źródła wspierają koncepcje techniczne w tym przewodniku. Przed zmianą systemu produkcyjnego zapoznaj się z aktualną dokumentacją. NGINX: Przewodnik dla początkujących nginx.org NGINX: ograniczanie żądań HTTP nginx.org NIST SP 800-207: Architektura Zero Trust nvlpubs.nist.gov OWASP: Zapobieganie atakom typu Denial of Service cheatsheetseries.owasp.org Wskazówki redakcyjne SwissOctet. Przykłady są ilustracyjne. Specyfikacje usług, dostępne opcje i warunki umowne należy zweryfikować osobno. POŁĄCZ WIEDZĘ Powiązana infrastruktura. Canvas Web Szwajcaria Vector VPS Szwajcaria Pulse NVMe Szwajcaria Transit 40 Szwajcaria ZACHOWAJ WĄTEK Twoje następne notatki z terenu. Poznaj wszystkie przewodniki NOTATKA Z TERENU / 01 + Operacje dnia drugiego Praktyczne Bazowy poziom utwardzenia Linux VPS, który możesz utrzymywać Zabezpiecz administrację, udostępniaj tylko wymagane usługi i ustanów aktualizacje oraz odzyskiwanie, nie blokując sobie dostępu. 6 min czytania Przeczytaj przewodnik NOTATKA Z TERENU / 02 + Web i onion Podstawy Hosting webowy lub VPS: wybierz pracę, którą chcesz wziąć na siebie Porównaj wymagania aplikacji, kontrolę i obowiązki utrzymaniowe, zamiast traktować VPS jako automatyczny następny krok dla każdej witryny. 6 min czytania Przeczytaj przewodnik NOTATKA Z TERENU / 03 + Web i onion Praktyczne Runbook przełączenia domeny, DNS i TLS dla nowego serwera Przygotuj razem routing nazw hostów, certyfikaty i wycofanie, aby migracja zmieniła serwer bez psucia tożsamości witryny ani bezpiecznych połączeń. 4 min czytania Przeczytaj przewodnik