Ochrona aplikacji i usług przy użyciu dedykowanego wystąpienia hosta w celu brokera żądań 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
Usługi w chmurze uwidaczniają punkty końcowe, które umożliwiają aplikacjom klienckim wywoływanie ich interfejsów API. Kod używany do implementowania interfejsów API wyzwala lub wykonuje kilka zadań, w tym uwierzytelnianie, autoryzację, walidację parametrów i niektóre lub wszystkie przetwarzanie żądań. Kod interfejsu API prawdopodobnie będzie uzyskiwać dostęp do magazynu 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. Można przeprowadzić oddzielenie za pomocą fasady lub dedykowanego zadania, które współdziała z klientami, a następnie przekazuje żądanie — na przykład za pośrednictwem odłączonego interfejsu — do hostów lub zadań, które obsługują żądanie. Na rysunku przedstawiono ogólny przegląd tego wzorca.
Wzorzec strażnika może służyć do ochrony magazynu lub może służyć jako bardziej kompleksowa fasada do ochrony wszystkich funkcji aplikacji. Należy wziąć pod uwagę następujące czynniki:
- Kontrolowana walidacja. Strażnik weryfikuje wszystkie żądania i odrzuca żądania, które nie spełniają wymagań dotyczących walidacji.
- Ograniczone ryzyko i ekspozycja. Strażnik nie ma dostępu do poświadczeń ani do kluczy używanych przez zaufanego hosta na potrzeby uzyskiwania dostępu do magazynu i usług. W przypadku naruszenia zabezpieczeń strażnika osoba atakująca nie uzyskuje 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, który jest wymagany, aby uzyskać dostęp 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. Umożliwia strażnikowi sprawdzenie żądań i podjęcie decyzji o tym, czy przekazać żądanie do zaufanego hosta, który wykonuje wymagane zadania. Podjęcie decyzji zwykle wymaga od strażnika sprawdzenia poprawności i oczyszczenia zawartości żądania przed przekazaniem go do zaufanego hosta.
Problemy i kwestie do rozważenia
Podczas podejmowania decyzji o sposobie wdrożenia tego wzorca należy rozważyć następujące punkty:
- Upewnij się, że zaufane hosty uwidaczniają tylko wewnętrzne lub chronione punkty końcowe, używane tylko przez strażnika. Zaufane hosty nie powinny uwidaczniać żadnych zewnętrznych punktów końcowych ani interfejsów.
- Strażnik musi działać w trybie ograniczonych uprawnień, który zazwyczaj wymaga uruchomienia strażnika i zaufanego hosta w oddzielnych hostach hostowanych lub maszynach wirtualnych.
- Strażnik nie powinien wykonywać żadnych operacji związanych z aplikacją ani usługami ani uzyskiwać dostępu do żadnych danych. Jego funkcją jest wyłącznie sprawdzanie poprawności i oczyszczanie żądań. Zaufane hosty mogą wymagać przeprowadzenia dodatkowej weryfikacji żądania, ale strażnik powinien przeprowadzić podstawową walidację.
- Użyj bezpiecznego kanału komunikacyjnego (HTTPS, SSL lub 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 strażnika prawdopodobnie wpłynie na wydajność ze względu na dodatkowe przetwarzanie i wymaganą komunikację sieciową.
- Wystąpienie strażnika może być pojedynczym punktem awarii. Aby zminimalizować wpływ awarii, rozważ wdrożenie wystąpień nadmiarowych i użycie mechanizmu skalowania automatycznego w celu zapewnienia pojemności w celu utrzymania dostępności.
Kiedy używać tego wzorca
Ten wzorzec jest przydatny w przypadku aplikacji, które:
- obsługa poufnych informacji
- uwidacznianie usług wymagających wysokiego stopnia ochrony przed złośliwymi atakami
- wykonywanie operacji o znaczeniu krytycznym, których nie można zakłócić.
- wymaganie przeprowadzenia weryfikacji żądania niezależnie od głównych zadań lub scentralizowanie tej weryfikacji w celu uproszczenia konserwacji i administrowania
Projekt obciążenia
Architekt powinien ocenić, w jaki sposób wzorzec usługi Gatekeeper może być używany w projekcie obciążenia, aby sprostać celom i zasadom opisanym w filarach platformy Azure Well-Architected Framework. Na przykład:
| 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. | Dodanie bramy do przepływu żądań umożliwia scentralizowanie funkcji zabezpieczeń, takich jak zapory aplikacji internetowej, ochrona przed atakami DDoS, wykrywanie botów, manipulowanie żądaniami, inicjowanie uwierzytelniania i kontrole autoryzacji. - SE:06 Kontrolki sieci - SE:10 Monitorowanie i wykrywanie zagrożeń |
| Wydajność pomaga wydajnie sprostać zapotrzebowaniu dzięki optymalizacjom skalowania, danych, kodu. | Ten wzorzec umożliwia zaimplementowanie ograniczania przepustowości na poziomie bramy zamiast implementowania kontroli szybkości na poziomie węzła. Koordynowanie stanu szybkości między wszystkimi węzłami nie jest z natury wydajne. - PE:03 Wybieranie usług |
Podobnie jak w przypadku każdej decyzji projektowej, należy rozważyć wszelkie kompromisy w stosunku do celów innych filarów, które mogą zostać wprowadzone przy użyciu tego wzorca.
Przykład
W scenariuszu hostowanym w chmurze ten wzorzec można zaimplementować przez oddzielenie roli strażnika lub maszyny wirtualnej od ról zaufanych i usług w aplikacji. Implementacja może używać wewnętrznego punktu końcowego, kolejki lub magazynu jako mechanizmu komunikacji pośredniej. Na rysunku przedstawiono użycie wewnętrznego punktu końcowego.
Powiązane zasoby
Wzorzec klucza portiera może również być istotny podczas implementowania wzorca strażnika. Podczas komunikowania się między rolami strażnika i zaufanymi warto zwiększyć bezpieczeństwo przy użyciu kluczy lub tokenów, które ograniczają uprawnienia dostępu do zasobów. Wzorzec opisuje użycie tokenu lub klucza, który zapewnia klientom ograniczony, bezpośredni dostęp do określonego zasobu lub usługi.