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.
Żą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ć.
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 |
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.
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.
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.
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.
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.
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.
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.