Wzorzec strażnika

Chroń aplikacje i usługi, używając dedykowanego składnika do pośredniczenia w żądaniach między klientami a aplikacją lub usługą. Broker weryfikuje i czyści żądania i może zapewnić dodatkową warstwę zabezpieczeń i ograniczyć obszar ataków systemu.

Kontekst i problem

Wiele usług w chmurze uwidacznia punkty końcowe, które umożliwiają aplikacjom klienckim wywoływanie interfejsów API przez Internet lub inną niezaufaną sieć. Kod, który implementuje interfejsy API wyzwala lub wykonuje kilka zadań, w tym uwierzytelnianie, autoryzację, walidację parametrów i niektóre lub wszystkie przetwarzanie żądań. Kod API prawdopodobnie uzyska dostęp do pamięci masowej i innych usług w imieniu klienta.

Jeśli złośliwy użytkownik naruszy system i uzyska dostęp do środowiska hostingu aplikacji, uwidocznione są jego mechanizmy zabezpieczeń i dostęp do danych i innych usług. W związku z tym złośliwy użytkownik może uzyskać nieograniczony dostęp do poświadczeń, kluczy magazynu, poufnych informacji i innych usług.

Rozwiązanie

Jednym z rozwiązań tego problemu jest oddzielenie kodu, który implementuje publiczne punkty końcowe z kodu, który przetwarza żądania i uzyskuje dostęp do magazynu. Rozdziel kod, stosując warstwę fasady, która komunikuje się z klientami i kieruje autoryzowane żądania przez wewnętrzny punkt końcowy, kolejkę lub brokera do komponentów obciążenia obsługujących operację biznesową. Diagram zawiera ogólne omówienie tego wzorca.

Diagram przedstawiający ogólny przegląd wzorca strażnika.

Możesz użyć wzorca Gatekeeper do ochrony magazynu lub użyć go jako bardziej kompleksowej fasady, aby chronić wszystkie funkcje aplikacji. Ważne czynniki to:

  • Kontrolowana walidacja: Strażnik weryfikuje wszystkie żądania i odrzuca żądania, które nie spełniają wymagań dotyczących walidacji.

  • Ograniczone ryzyko i narażenie: Ryzyko i ekspozycja są zmniejszane, ponieważ strażnik nie uzyskuje dostępu do poświadczeń ani kluczy używanych przez zaufanego hosta do uzyskiwania dostępu do magazynu i usług. Jeśli strażnik zostanie naruszony, osoby atakujące nie mogą uzyskać dostępu do tych poświadczeń ani kluczy.

  • Odpowiednie zabezpieczenia: Strażnik działa w trybie ograniczonych uprawnień, podczas gdy reszta aplikacji działa w trybie pełnego zaufania wymaganego do uzyskania dostępu do magazynu i usług. Jeśli zostaną naruszone zabezpieczenia strażnika, nie może on bezpośrednio uzyskać dostępu do usług i danych aplikacji.

Ten wzorzec działa jak zapora w typowej topografii sieciowej. W przeciwieństwie do tradycyjnej zapory umożliwia strażnikowi szczegółowe badanie żądań i podejmowanie decyzji opartej na aplikacji na temat tego, czy przekazać żądanie do zaufanego hosta, który wykonuje wymagane zadania. Ta decyzja zwykle wymaga od strażnika zweryfikowania i oczyszczenia zawartości żądania przed przekazaniem jej do zaufanego hosta. Strażniki mogą autoryzować żądanie, szukać nieoczekiwanej lub nieprawidłowej zawartości ładunku, wykonywać ograniczanie szybkości i wykonywać różne inne kontrole.

Problemy i zagadnienia

Podczas podejmowania decyzji o zaimplementowaniu tego wzorca należy wziąć pod uwagę następujące kwestie:

  • Upewnij się, że zaufane hosty udostępniają tylko wewnętrzne lub chronione punkty końcowe, z których korzysta tylko gatekeeper. Zaufane hosty nie powinny uwidaczniać żadnych zewnętrznych punktów końcowych ani interfejsów.

  • Strażnik musi działać w trybie ograniczonych uprawnień. W praktyce umieść bramę pośredniczącą i zaufany system zaplecza w oddzielnych granicach zasobów obliczeniowych oraz utrzymuj punkty końcowe systemu zaplecza jako prywatne.

  • Strażnik nie powinien wykonywać przetwarzania związanego z aplikacją lub usługami ani danymi dostępu. Jej funkcja polega wyłącznie na weryfikowaniu i czyszczeniu żądań. Zaufane hosty mogą wymagać dodatkowej walidacji żądań, ale gatekeeper powinien przeprowadzać zasadniczą walidację.

  • Używaj bezpiecznego kanału komunikacyjnego, takiego jak HTTPS, Secure Sockets Layer (SSL) lub Transport Layer Security (TLS) między strażnikiem a zaufanymi hostami lub zadaniami, jeśli to możliwe. Niektóre środowiska hostingu nie obsługują jednak protokołu HTTPS na wewnętrznych punktach końcowych.

  • Dodanie dodatkowej warstwy w celu zaimplementowania wzorca gatekeeper może mieć wpływ na wydajność z powodu dodatkowego przetwarzania i wymaganej komunikacji sieciowej.

  • Strażnik może być pojedynczym punktem awarii (SPoF). Aby zminimalizować wpływ awarii, rozważ wdrożenie nadmiarowych wystąpień i użycie mechanizmu skalowania automatycznego w celu zapewnienia pojemności i utrzymania dostępności.

Kiedy należy używać tego wzorca

Użyj tego wzorca, gdy:

  • Przetwarzasz informacje wrażliwe.

  • Uwidaczniasz usługi wymagające silnej ochrony przed złośliwym ruchem.

  • Wykonujesz operacje o znaczeniu krytycznym, które nie mogą tolerować bezpośredniej ekspozycji na usługi zaplecza.

  • Potrzebujesz, aby walidacja i sanityzacja żądań były oddzielone od głównej logiki biznesowej.

Ten wzorzec może nie być odpowiedni w następujących przypadkach:

  • Wymagania dotyczące zabezpieczeń i walidacji można spełnić za pomocą wbudowanych mechanizmów kontrolnych platformy po stronie usługi back-endowej, bez dodawania dedykowanej warstwy pośredniczącej.

  • Dodano przeskoki sieciowe i opóźnienie walidacji, które naruszają ścisłe wymagania dotyczące opóźnień na poziomie końcowym.

Projektowanie obciążenia pracy

Oceń, jak zastosować wzorzec Gatekeeper w projekcie obciążenia roboczego, aby uwzględnić cele i zasady omówione w filarach Azure Well-Architected Framework. Poniższa tabela zawiera wskazówki dotyczące tego, jak ten wzorzec obsługuje cele poszczególnych filarów.

Filar Jak ten wzorzec obsługuje cele filaru
Decyzje dotyczące projektowania zabezpieczeń pomagają zapewnić poufność, integralność i dostępność danych i systemów obciążenia. Strażnik w przepływie żądań ułatwia scentralizowanie funkcji zabezpieczeń, takich jak zapory aplikacji internetowej, ochrona przed atakami DDoS, wykrywanie botów, manipulowanie żądaniami, inicjowanie uwierzytelniania i sprawdzanie autoryzacji.

- SE:06 Kontrolki sieci
- SE:10 Monitorowanie i wykrywanie zagrożeń
Efektywność wydajności pomaga wydajnie sprostać wymaganiom dzięki optymalizacjom skalowania, danych i kodu. Ten wzorzec służy do implementowania ograniczania przepustowości na poziomie strażnika, a nie implementowania kontroli szybkości na poziomie węzła. Koordynacja stanu szybkości między wszystkimi węzłami nie jest z natury wydajna.

- PE:03 Wybieranie usług

Jeśli ten wzorzec wprowadza kompromisy w ramach filaru, rozważ je przed celami innych filarów.

Example

Wzorzec Gatekeeper zwykle implementuje warstwową ścieżkę obsługi żądania, w której każda warstwa ma ściśle określoną rolę i ograniczony zakres zaufania.

Diagram przedstawiający warstwowy wzorzec Gatekeeper.

Pobierz plik programu Visio tej architektury.

W tym rozwiązaniu Azure Application Gateway i usługa Azure Web Application Firewall stanowią pierwszą linię ochrony. Sprawdza ruch dostępny z Internetu i stosuje mechanizmy kontroli zabezpieczeń, zanim ruch osiągnie warstwę interfejsu API. Azure API Management jest wewnętrznym strażnikiem. Stosuje mechanizmy kontroli specyficzne dla interfejsu API i przekazuje tylko zatwierdzony ruch do prywatnych systemów zaplecza.

Na przykład Azure Web Application Firewall może wykrywać i blokować wzorce iniekcji SQL oraz ataków typu cross-site scripting (XSS), wymuszać reguły dotyczące protokołu i rozmiaru żądań oraz stosować filtrowanie botów i adresów IP, zanim żądania dotrą do usługi API Management lub prywatnych systemów zaplecza.

Gdy używasz usługi API Management w warstwie wewnętrznej, usługa ta stosuje zasady do żądań przychodzących i odpowiedzi wychodzących w potoku przetwarzania bramy. Aby uzyskać więcej informacji na temat sposobu przetwarzania żądań i odpowiedzi przez usługę API Management, zobacz Zasady w usłudze API Management. Informacje o opcjach zasad, takich jak walidacja tokenu JSON Web Token (JWT), ograniczanie liczby żądań, przekształcanie nagłówków i kształtowanie odpowiedzi, można znaleźć w dokumencie Dokumentacja referencyjna zasad usługi API Management.

Konsekwentnie używaj tożsamości zarządzanych dla zasobów platformy Azure do uwierzytelniania między usługami w tym scenariuszu. Na przykład usługa API Management może używać zasad uwierzytelniania przy użyciu tożsamości zarządzanej, aby uzyskiwać tokeny Microsoft Entra na potrzeby wywołań zaplecza bez przechowywania wpisów tajnych.

Zaplecze pozostaje prywatne. Na przykład zaplecze może być aplikacją Azure App Service korzystającą z prywatnego punktu końcowego, dzięki czemu dostęp do aplikacji jest możliwy prywatnie.

W przypadku obciążeń konteneryzowanych alternatywa może zastąpić usługę API Management i ścieżką wewnętrzną usługi App Service obliczeniami opartymi na ruchu przychodzącym:

W tych alternatywach ingress może kierować ruch na podstawie hosta lub ścieżki, terminować TLS i udostępniać usługi dostępne wyłącznie wewnętrznie. Określone możliwości, takie jak limity żądań i reguły zezwalania lub odmowy, zależą od wybranej implementacji ruchu przychodzącego. W każdym przypadku zachowaj mechanizmy kontrolne bramy: stosuj walidację i egzekwowanie zasad na wejściu oraz utrzymuj usługi zaplecza dostępne wyłącznie przez tę bramę.

Każda warstwa na tej ścieżce generuje logi i metryki, które należy centralizować. Dzienniki diagnostyczne usługi Azure Web Application Firewall rejestrują dopasowane i zablokowane reguły dla każdego żądania. Usługa API Management generuje dzienniki bramy, które zawierają czas trwania żądania, kody odpowiedzi i wyniki działania zasad. Usługi zaplecza emitują dane telemetryczne na poziomie aplikacji. Zbieraj te dzienniki i metryki w Azure Monitor i kieruj je do obszaru roboczego Log Analytics, aby umożliwić ujednolicone wykonywanie zapytań. Ustandaryzuj kompleksową korelację żądań, generując lub przekazując identyfikator korelacji na brzegu sieci i propagując je za pomocą usługi API Management i zaplecza (na przykład za pośrednictwem nagłówków żądań i rozproszonego kontekstu śledzenia), aby jedna transakcja pozostała śledzona we wszystkich warstwach. Użyj Microsoft Defender dla Chmury, aby wyświetlać zalecenia dotyczące bezpieczeństwa we wszystkich składnikach Gatekeepera. Skonfiguruj alerty dotyczące nietypowych wskaźników blokowania w usłudze Azure Web Application Firewall lub nagłych wzrostów liczby błędów w usłudze API Management, aby wykrywać zagrożenia, zanim dotrą do prywatnych systemów zaplecza.

Następne kroki

Poniższe wskazówki mogą być istotne podczas implementowania tego wzorca:

Następujące wzorce projektowe chmury obliczeniowej są często używane razem z wzorcem Gatekeeper:

  • Last updated on