Edytuj

Ograniczanie komunikacji międzyusługowej

Azure
Identyfikator Microsoft Entra
Azure App Service

Ten przykładowy scenariusz ogranicza komunikację między dwiema usługami zaplecza platformy Azure w warstwach aplikacji i sieci. Komunikacja może przepływać tylko między usługami, które jawnie ją zezwalają, przestrzegając zasady najniższych uprawnień. W tym przykładzie użyto usługi aplikacja systemu Azure Service do hostowania usług, ale możesz użyć podobnych technik dla usługi Azure Functions Apps.

Ograniczenia komunikacji międzyusługowej są tylko jedną częścią ogólnej strategii zabezpieczeń opartej na starannym planowaniu, modelowaniu zagrożeń i cyklu projektowania zabezpieczeń. Ogólne planowanie zabezpieczeń powinno obejmować wymagania biznesowe, zgodności, regulacyjne i inne wymagania niefunkcjonalne.

Potencjalne przypadki użycia

Podczas gdy bieżący scenariusz koncentruje się na ograniczeniach sieci, wiele organizacji korzysta teraz z modelu zabezpieczeń zerowego zaufania, który zakłada naruszenie, więc warstwa sieci ma drugorzędne znaczenie.

Architektura

Diagram showing both network layer and application layer communications restrictions between two Azure App Service backend services.

Pobierz plik programu Visio tej architektury.

Przepływ danych

Na diagramie przedstawiono ograniczoną komunikację z usługi A do usługi B. Autoryzacja oparta na tokenach ogranicza dostęp do warstwy aplikacji, a punkty końcowe usługi ograniczają dostęp do warstwy sieciowej.

Autoryzacja oparta na tokenach

Biblioteka zgodna z protokołem OpenID Połączenie (OIDC), taka jak biblioteka Microsoft Authentication Library (MSAL), obsługuje ten przepływ poświadczeń klienta opartych na tokenach. Aby uzyskać więcej informacji, zobacz Scenariusz: aplikacja demona, która wywołuje internetowe interfejsy API i przykładową aplikację dla scenariusza demona.

  1. Zarówno usługa A, jak i usługa B rejestrują się w identyfikatorze Entra firmy Microsoft. Usługa A ma poświadczenia klienta w formularzu udostępnionego wpisu tajnego lub certyfikatu.
  2. Usługa A może użyć własnych poświadczeń klienta, aby zażądać tokenu dostępu dla usługi B.
  3. Identyfikator Entra firmy Microsoft udostępnia token dostępu z odbiorcą usługi B lub oświadczeniem o wartości aud .
  4. Usługa A wprowadza token jako token elementu nośnego w nagłówku autoryzacji HTTP żądania do usługi B zgodnie ze specyfikacją użycia tokenu elementu nośnego OAuth 2.0.
  5. Usługa B weryfikuje token , aby upewnić się, że aud oświadczenie jest zgodne z aplikacją usługi B.

Usługa B korzysta z jednej z następujących metod, aby upewnić się, że tylko w szczególności dozwolonych klientów, usługa A w tym przypadku może uzyskać dostęp:

  • Zweryfikuj oświadczenie identyfikatora appid tokenu. Usługa B może zweryfikować oświadczenie appid tokenu, które identyfikuje, która aplikacja zarejestrowana przez firmę Microsoft Entra zażądała tokenu. Usługa B jawnie sprawdza oświadczenie względem znanej listy wywołujących kontrolę dostępu.

  • Sprawdź role w tokenie. Podobnie usługa B może sprawdzić niektóre role zgłoszone w tokenie przychodzącym, aby upewnić się, że usługa A ma jawne uprawnienia dostępu.

  • Wymagaj przypisania użytkownika. Alternatywnie właściciel usługi B lub administrator może skonfigurować identyfikator Entra firmy Microsoft, aby wymagać przypisania użytkownika, więc tylko aplikacje, które mają jawne uprawnienia do aplikacji Service B, mogą uzyskać token w kierunku usługi B. Usługa B nie musi sprawdzać określonych ról, chyba że wymaga tego logika biznesowa.

    Aby skonfigurować wymaganie przypisania użytkownika w celu uzyskania dostępu do usługi B:

    1. W usłudze Microsoft Entra ID włącz przypisanie użytkownika w usłudze B.
    2. Uwidocznij co najmniej jedną rolę aplikacji w usłudze B, której usługa A może poprosić o uprawnienie. Typ AllowedMemberTypes dla tej roli musi zawierać wartość Application.
    3. Zażądaj uprawnień aplikacji dla usługi A do uwidocznionej roli usługi B.
      1. W sekcji Uprawnienia interfejsu API rejestracji aplikacji Service A wybierz pozycję Dodaj uprawnienie, a następnie wybierz aplikację Service B z listy.
      2. Na ekranie Żądanie uprawnień interfejsu API wybierz pozycję Uprawnienia aplikacji, ponieważ ta aplikacja zaplecza jest uruchamiana bez zalogowanego użytkownika. Wybierz rolę uwidocznionej usługi B, a następnie wybierz pozycję Dodaj uprawnienia.
    4. Udziel zgody administratora na żądanie uprawnień aplikacji Service A. Tylko właściciel usługi B lub administrator może wyrazić zgodę na żądanie uprawnień usługi A.

Punkty końcowe usługi

Dolna połowa diagramu architektury pokazuje, jak ograniczyć komunikację międzyusługową w warstwie sieciowej:

  1. Aplikacja internetowa Service A używa regionalnej integracji z siecią wirtualną do kierowania całej komunikacji wychodzącej za pośrednictwem prywatnego adresu IP w zakresie adresów IP podsieci integracji.
  2. Usługa B ma punkty końcowe usługi, które zezwalają na komunikację przychodzącą tylko z aplikacji internetowych w podsieci integracji usługi B.

Aby uzyskać więcej informacji, zobacz Konfigurowanie ograniczeń dostępu do usługi aplikacja systemu Azure.

Elementy

W tym scenariuszu są używane następujące usługi platformy Azure:

Alternatywy

Istnieje kilka alternatyw dla przykładowego scenariusza.

Tożsamość zarządzana

Zamiast rejestrować się jako aplikacja w usłudze Microsoft Entra ID, usługa A może użyć tożsamości zarządzanej do pobrania tokenu dostępu. Tożsamość zarządzana zwalnia operatorów od konieczności zarządzania poświadczeniami na potrzeby rejestracji aplikacji.

Tożsamość zarządzana umożliwia usłudze A pobranie tokenu, ale nie zapewnia rejestracji aplikacji Entra firmy Microsoft. Aby inne usługi zażądały tokenu dostępu dla samej usługi A, usługa A nadal potrzebuje rejestracji aplikacji Firmy Microsoft Entra.

Nie można przypisać tożsamości zarządzanej do roli aplikacji za pośrednictwem witryny Azure Portal, tylko za pośrednictwem wiersza polecenia programu Azure PowerShell. Aby uzyskać więcej informacji, zobacz Przypisywanie dostępu tożsamości zarządzanej do roli aplikacji przy użyciu programu PowerShell.

Azure Functions

Usługi można hostować w usłudze Azure Functions zamiast usługi App Service. Aby ograniczyć dostęp do warstwy sieciowej przy użyciu regionalnej integracji z siecią wirtualną, musisz hostować aplikacje usługi Functions w planie usługi App Service lub planie Premium. Aby uzyskać więcej informacji, zobacz Opcje sieci usługi Azure Functions.

Wbudowane uwierzytelnianie i autoryzacja usługi App Service

Zgodnie z projektem ten scenariusz przenosi kod autoryzacji z resztą logiki biznesowej, wykonując walidację tokenu w ramach kodu aplikacji. Wbudowane uwierzytelnianie i autoryzacja usługi App Service lub Easy Auth mogą również przeprowadzać podstawową walidację tokenu przed wysłaniem żądania do usługi. Następnie usługa opiera się na infrastrukturze hostingu w celu odrzucenia nieautoryzowanych żądań.

Aby skonfigurować uwierzytelnianie i autoryzację usługi App Service, ustaw zachowanie autoryzacji na Zaloguj się przy użyciu identyfikatora Entra firmy Microsoft. To ustawienie weryfikuje tokeny i ogranicza dostęp tylko do prawidłowych tokenów.

Wadą korzystania z usługi Easy Auth jest to, że usługa traci ochronę uwierzytelniania i autoryzacji, jeśli zostanie przeniesiona gdzie indziej. Chociaż uwierzytelnianie i autoryzacja usługi App Service działa w prostych scenariuszach, złożone wymagania dotyczące autoryzacji powinny używać logiki z poziomu kodu aplikacji.

Punkty końcowe usługi a prywatne punkty końcowe

W tym scenariuszu są używane punkty końcowe usługi, a nie prywatne punkty końcowe, ponieważ tylko punkty końcowe usługi zezwalają na ograniczanie dostępu do aplikacji internetowej z danej podsieci. Filtrowanie ruchu przychodzącego w prywatnych punktach końcowych nie jest obsługiwane za pośrednictwem sieciowych grup zabezpieczeń ani ograniczeń dostępu usługi App Service. Każda usługa z siecią może komunikować się z prywatnym punktem końcowym aplikacji internetowej. Ogranicza to użyteczność prywatnego punktu końcowego do blokowania ruchu w warstwie sieciowej.

Zagadnienia do rozważenia

  • Regionalna integracja sieci wirtualnej usługi App Service zapewnia jedną podsieć integracji dla każdego planu usługi App Service. Wszystkie aplikacje internetowe w tym samym planie są zintegrowane z tą samą podsiecią i współużytkują ten sam zestaw prywatnych wychodzących adresów IP. Odbieranie usług nie może odróżnić aplikacji internetowej, z której pochodzi ruch. Jeśli musisz zidentyfikować źródłową aplikację internetową, musisz wdrożyć aplikacje internetowe w oddzielnych planach usługi App Service, z których każda ma własną podsieć integracji.

  • Każde wystąpienie procesu roboczego w planie usługi App Service zajmuje oddzielny prywatny adres IP w podsieci integracji. Aby zaplanować skalowanie, upewnij się, że podsieć integracji jest wystarczająco duża, aby uwzględnić oczekiwaną skalę.

Optymalizacja kosztów

Ceny dla tego scenariusza zależą od konkretnej infrastruktury i wymagań. Identyfikator Entra firmy Microsoft ma warstwę Bezpłatna do warstwy Premium, w zależności od potrzeb. Koszty usługi aplikacja systemu Azure lub innych hostów różnią się w zależności od określonych wymagań dotyczących skalowania i zabezpieczeń, zgodnie z opisem w temacie Alternatywy i zagadnienia.

Aby obliczyć koszty dla danego scenariusza, zobacz kalkulator cen platformy Azure.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

Następne kroki