Ta architektura bazowa jest oparta na podstawowej architekturze aplikacji internetowej i rozszerza ją w celu zapewnienia szczegółowych wskazówek dotyczących projektowania bezpiecznej, strefowo nadmiarowej i wysoce dostępnej aplikacji internetowej na platformie Azure. Architektura uwidacznia publiczny punkt końcowy za pośrednictwem usługi aplikacja systemu Azure Gateway z zaporą aplikacji internetowej. Kieruje żądania do usługi aplikacja systemu Azure za pośrednictwem usługi Private Link. Aplikacja usługi App Service używa integracji sieci wirtualnej i usługi Private Link, aby bezpiecznie komunikować się z usługami PaaS platformy Azure, takimi jak Azure Key Vault i Azure SQL Database.
Ważne
Wskazówki są wspierane przez przykładową implementację, która prezentuje podstawową implementację usługi App Service na platformie Azure. Ta implementacja może służyć jako podstawa do dalszego opracowywania rozwiązań w pierwszym kroku w kierunku produkcji.
Architektura
Rysunek 1. Architektura usługi aplikacja systemu Azure wg planu bazowego
Pobierz plik programu Visio z tą architekturą.
Składniki
Wiele składników tej architektury jest takich samych jak podstawowa architektura aplikacji internetowej. Poniższa lista zawiera tylko zmiany w podstawowej architekturze.
- Application Gateway to moduł równoważenia obciążenia w warstwie 7 (HTTP/S) i internetowy menedżer ruchu. Używa routingu opartego na ścieżkach URL w celu dystrybucji ruchu przychodzącego między strefami dostępności i odciąża szyfrowanie w celu zwiększenia wydajności aplikacji.
- Zapora aplikacji internetowej (WAF) to natywna dla chmury usługa, która chroni aplikacje internetowe przed typowymi programami wykorzystującymi luki, takie jak wstrzyknięcie kodu SQL i wykonywanie skryptów między witrynami. Zapora aplikacji internetowej zapewnia wgląd w ruch do i z aplikacji internetowej, umożliwiając monitorowanie i zabezpieczanie aplikacji.
- Azure Key Vault to usługa, która bezpiecznie przechowuje wpisy tajne, klucze szyfrowania i certyfikaty oraz zarządza nimi. Centralizuje zarządzanie poufnymi informacjami.
- Azure Virtual Network to usługa, która umożliwia tworzenie izolowanych i bezpiecznych prywatnych sieci wirtualnych na platformie Azure. W przypadku aplikacji internetowej w usłudze App Service potrzebna jest podsieć sieci wirtualnej do korzystania z prywatnych punktów końcowych na potrzeby bezpiecznej komunikacji między zasobami.
- Usługa Private Link umożliwia klientom uzyskiwanie dostępu do usług Platformy jako usługi (PaaS) platformy Azure bezpośrednio z prywatnych sieci wirtualnych bez korzystania z publicznego adresowania IP.
- Azure DNS to usługa hostingu dla domen DNS, która zapewnia rozpoznawanie nazw przy użyciu infrastruktury platformy Microsoft Azure. Prywatna strefa DNS strefy umożliwiają mapowanie w pełni kwalifikowanej nazwy domeny (FQDN) usługi na adres IP prywatnego punktu końcowego.
Sieć
Zabezpieczenia sieci są podstawą architektury bazowej usług App Services (patrz Rysunek 2). Na wysokim poziomie architektura sieci zapewnia następujące elementy:
- Pojedynczy bezpieczny punkt wejścia dla ruchu klienckiego
- Ruch sieciowy jest filtrowany
- Dane przesyłane są szyfrowane kompleksowo przy użyciu protokołu TLS
- Eksfiltracja danych jest zminimalizowana przez utrzymywanie ruchu na platformie Azure za pomocą usługi Private Link
- Zasoby sieciowe są logicznie grupowane i odizolowane od siebie za pośrednictwem segmentacji sieci
Przepływy sieciowe
Rysunek 2. Architektura sieciowa aplikacji usługi aplikacja systemu Azure
Poniżej przedstawiono opisy przychodzącego przepływu ruchu internetowego do wystąpienia usługi App Service i przepływu z usługi App Service do usług platformy Azure.
Przepływ przychodzący
- Użytkownik wysyła żądanie do publicznego adresu IP usługi Application Gateway.
- Reguły zapory aplikacji internetowej są oceniane. Reguły zapory aplikacji internetowej pozytywnie wpływają na niezawodność systemu, chroniąc przed różnymi atakami, takimi jak wykonywanie skryptów między witrynami (XSS) i wstrzyknięcie kodu SQL. aplikacja systemu Azure Gateway zwraca błąd do osoby żądającego, jeśli zostanie naruszona reguła zapory aplikacji internetowej i przetwarzanie zostanie zatrzymane. Jeśli żadne reguły zapory aplikacji internetowej nie zostaną naruszone, usługa Application Gateway kieruje żądanie do puli zaplecza, co w tym przypadku jest domeną domyślną usługi App Service.
- Prywatna strefa
privatelink.azurewebsites.net
DNS jest połączona z siecią wirtualną. Strefa DNS ma rekord A, który mapuje domyślną domenę usługi App Service na prywatny adres IP prywatnego punktu końcowego usługi App Service. Ta połączona prywatna strefa DNS umożliwia usłudze Azure DNS rozpoznawanie domyślnej domeny z prywatnym adresem IP punktu końcowego. - Żądanie jest kierowane do wystąpienia usługi App Service za pośrednictwem prywatnego punktu końcowego.
Przepływ usług App Service do usługi Azure PaaS
- Usługa App Service wysyła żądanie do nazwy DNS wymaganej usługi platformy Azure. Żądanie może dotyczyć usługi Azure Key Vault w celu uzyskania wpisu tajnego, usługi Azure Storage w celu pobrania pliku zip publikowania, usługi Azure SQL Database lub dowolnej innej usługi platformy Azure obsługującej usługę Private Link. Funkcja integracji sieci wirtualnej usługi App Service kieruje żądanie za pośrednictwem sieci wirtualnej.
- Podobnie jak krok 3 w przepływie przychodzącym, połączona prywatna strefa DNS ma rekord A, który mapuje domenę usługi platformy Azure na prywatny adres IP prywatnego punktu końcowego. Ponownie ta połączona prywatna strefa DNS umożliwia usłudze Azure DNS rozpoznawanie domeny z prywatnym adresem IP punktu końcowego usługi.
- Żądanie jest kierowane do usługi za pośrednictwem prywatnego punktu końcowego.
Ruch przychodzący do usługi App Services
Usługa Application Gateway to zasób regionalny spełniający wymagania tej architektury punktu odniesienia. Application Gateway to skalowalny, regionalny moduł równoważenia obciążenia warstwy 7 obsługujący funkcje, takie jak zapora aplikacji internetowej i odciążanie protokołu TLS. Podczas implementowania usługi Application Gateway dla ruchu przychodzącego w usługach aplikacja systemu Azure Należy wziąć pod uwagę następujące kwestie.
- Wdrażanie usługi Application Gateway i konfigurowanie zasad zapory aplikacji internetowej przy użyciu zestawu reguł zarządzanych przez firmę Microsoft. Użyj trybu zapobiegania, aby zapobiec atakom internetowym, co może spowodować, że usługa pochodzenia (usługa App Service w architekturze) stanie się niedostępna.
- Zaimplementuj kompleksowe szyfrowanie TLS.
- Użyj prywatnych punktów końcowych, aby zaimplementować przychodzący prywatny dostęp do usługi App Service.
- Rozważ zaimplementowanie skalowania automatycznego dla usługi Application Gateway, aby łatwo dostosować się do dynamicznych przepływów ruchu.
- Rozważ użycie minimalnej liczby wystąpień skalowania nie mniejszej niż trzy i zawsze używaj wszystkich stref dostępności, które obsługuje region. Chociaż usługa Application Gateway jest wdrażana w sposób o wysokiej dostępności, nawet w przypadku pojedynczego wystąpienia skalowania tworzenie nowego wystąpienia po awarii może potrwać do siedmiu minut. Wdrażanie wielu wystąpień w Strefy dostępności pomaga zagwarantować, że po awarii wystąpienie jest uruchomione podczas tworzenia nowego wystąpienia.
- Wyłącz dostęp do sieci publicznej w usłudze App Service, aby zapewnić izolację sieci. W pliku Bicep można to zrobić, ustawiając wartość w obszarze
publicNetworkAccess: 'Disabled'
properties/siteConfig.
Przepływ z usług App Services do usług platformy Azure
Ta architektura używa integracji sieci wirtualnej dla usługi App Service, w szczególności do kierowania ruchu do prywatnych punktów końcowych za pośrednictwem sieci wirtualnej. Architektura linii bazowej nie umożliwia całego routingu ruchu, aby wymusić cały ruch wychodzący przez sieć wirtualną, tylko ruch wewnętrzny, taki jak ruch związany z prywatnymi punktami końcowymi.
Usługi platformy Azure, które nie wymagają dostępu z publicznego Internetu, powinny mieć włączone prywatne punkty końcowe i wyłączyć publiczne punkty końcowe. Prywatne punkty końcowe są używane w całej tej architekturze w celu zwiększenia bezpieczeństwa, umożliwiając usłudze App Service łączenie się z usługami Private Link bezpośrednio z prywatnej sieci wirtualnej bez używania publicznego adresowania IP.
W tej architekturze wszystkie usługi Azure SQL Database, Azure Storage i Key Vault mają wyłączone publiczne punkty końcowe. Zapory usług platformy Azure są używane tylko do zezwalania na ruch z innych autoryzowanych usług platformy Azure. Należy skonfigurować inne usługi platformy Azure z prywatnymi punktami końcowymi, takimi jak Azure Cosmos DB i Azure Redis Cache. W tej architekturze usługa Azure Monitor nie używa prywatnego punktu końcowego, ale może.
Architektura punktu odniesienia implementuje prywatną strefę DNS dla każdej usługi. Prywatna strefa DNS zawiera rekord A mapowany między w pełni kwalifikowaną nazwą domeny usługi a prywatnym adresem IP prywatnego punktu końcowego. Strefy są połączone z siecią wirtualną. Prywatna strefa DNS grupy stref zapewniają, że rekordy DNS łącza prywatnego są tworzone i aktualizowane automatycznie.
Podczas implementowania integracji sieci wirtualnej i prywatnych punktów końcowych należy wziąć pod uwagę następujące kwestie.
- Skorzystaj ze wskazówek dotyczących konfiguracji strefy DNS usług platformy Azure na potrzeby nazewnictwa prywatnych stref DNS.
- Skonfiguruj zapory usług, aby upewnić się, że konto magazynu, magazyn kluczy, usługa SQL Database i inne usługi platformy Azure mogą być połączone tylko prywatnie.
- Ustaw domyślną regułę dostępu do sieci konta magazynu, aby odmówić całego ruchu.
- Włącz usługę Key Vault dla usługi Private Link.
- Odmowa dostępu do sieci publicznej do usługi Azure SQL.
Segmentacja i zabezpieczenia sieci wirtualnej
Sieć w tej architekturze ma oddzielne podsieci dla składników integracji usługi Application Gateway, usługi App Service i prywatnych punktów końcowych. Każda podsieć ma sieciową grupę zabezpieczeń, która ogranicza zarówno ruch przychodzący, jak i wychodzący dla tych podsieci, tylko do tego, co jest wymagane. W poniższej tabeli przedstawiono uproszczony widok reguł sieciowej grupy zabezpieczeń dodaną do każdej podsieci. Tabela zawiera nazwę reguły i funkcję.
Podsieć | Przychodzący | Wychodzący |
---|---|---|
snet-AppGateway | AppGw.In.Allow.ControlPlane : Zezwalaj na dostęp do płaszczyzny kontroli ruchu przychodzącegoAppGw.In.Allow443.Internet : Zezwalaj na dostęp do przychodzącego internetowego protokołu HTTPS |
AppGw.Out.Allow.AppServices : Zezwalaj na dostęp wychodzący do podsieci AppServicesSubnetAppGw.Out.Allow.PrivateEndpoints : Zezwalaj na dostęp wychodzący do usługi PrivateEndpointsSubnetAppPlan.Out.Allow.AzureMonitor : Zezwalaj na dostęp wychodzący do usługi Azure Monitor |
snet-PrivateEndpoints | Reguły domyślne: Zezwalaj na ruch przychodzący z sieci wirtualnej | Reguły domyślne: Zezwalaj na ruch wychodzący do sieci wirtualnej |
snet-AppService | Reguły domyślne: Zezwalaj na ruch przychodzący z sieci wirtualnej | AppPlan.Out.Allow.PrivateEndpoints : Zezwalaj na dostęp wychodzący do usługi PrivateEndpointsSubnetAppPlan.Out.Allow.AzureMonitor : Zezwalaj na dostęp wychodzący do usługi Azure Monitor |
Podczas implementowania segmentacji i zabezpieczeń sieci wirtualnej należy wziąć pod uwagę następujące kwestie.
- Włącz ochronę przed atakami DDoS dla sieci wirtualnej z podsiecią, która jest częścią bramy aplikacji z publicznym adresem IP.
- W miarę możliwości dodaj sieciową grupę zabezpieczeń do każdej podsieci. Należy użyć najostrzejszych reguł, które umożliwiają korzystanie z pełnej funkcjonalności rozwiązania.
- Użyj grup zabezpieczeń aplikacji. Grupy zabezpieczeń aplikacji umożliwiają grupowanie sieciowych grup zabezpieczeń, co ułatwia tworzenie reguł w złożonych środowiskach.
Przykładem schematu podsieci wirtualnej może być:
Type | Nazwisko | Zakres adresów |
---|---|---|
Virtual Network | Przedrostek adresu | 10.0.0.0/16 |
Podsieć | GatewaySubnet | 10.0.1.0/24 |
Podsieć | AppServicesSubnet | 10.0.0.0/24 |
Podsieć | PrivateEndpointsSubnet | 10.0.2.0/27 |
Podsieć | AgenciSubject | 10.0.2.32/27 |
Dokumentacja azure-samples\app-service-baseline-implementation
Kwestie wymagające rozważenia
Te zagadnienia implementują filary struktury Azure Well-Architected Framework, która jest zestawem wytycznych, które mogą służyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Microsoft Azure Well-Architected Framework.
Niezawodność
Niezawodność zapewnia, że aplikacja może spełnić zobowiązania podjęte przez klientów. Aby uzyskać więcej informacji, zobacz Omówienie filaru niezawodności.
Podstawowa architektura usługi App Services koncentruje się na nadmiarowości strefowej dla kluczowych usług regionalnych. Strefy dostępności są fizycznie oddzielone lokalizacjami w obrębie regionu. Zapewniają nadmiarowość strefową na potrzeby obsługi usług, gdy co najmniej dwa wystąpienia są wdrażane w regionach pomocniczych. W przypadku przestoju w jednej strefie inne strefy mogą nadal nie mieć wpływu.
Architektura zapewnia również wystarczającą liczbę wystąpień usług platformy Azure, aby sprostać zapotrzebowaniu. Poniższe sekcje zawierają wskazówki dotyczące niezawodności kluczowych usług w architekturze. Dzięki temu strefy dostępności pomagają w osiągnięciu niezawodności, zapewniając wysoką dostępność i odporność na uszkodzenia.
Application Gateway
Wdróż bramę aplikacja systemu Azure w wersji 2 w konfiguracji strefowo nadmiarowej. Rozważ użycie minimalnej liczby wystąpień skalowania wynoszącej nie mniej niż trzy, aby uniknąć sześciominutowego czasu uruchamiania dla wystąpienia usługi Application Gateway, jeśli wystąpi awaria.
App Services
- Wdróż co najmniej trzy wystąpienia usług App Services z obsługą stref dostępności.
- Zaimplementuj punkty końcowe sprawdzania kondycji w aplikacjach i skonfiguruj funkcję sprawdzania aplikacji Kondycja usługi, aby przekierować żądania z dala od wystąpień w złej kondycji. Aby uzyskać więcej informacji na temat sprawdzania kondycji usługi App Service, zobacz Monitorowanie wystąpień usługi App Service przy użyciu kontroli kondycji. Aby uzyskać więcej informacji na temat implementowania punktów końcowych kontroli kondycji w aplikacjach ASP.NET, zobacz Kontrole kondycji w programie ASP.NET Core.
- Pojemność overprovision w celu obsługi błędów strefy.
SQL Database
- Wdróż usługę Azure SQL DB Ogólnego przeznaczenia, Premium lub Krytyczne dla działania firmy z włączoną nadmiarowością strefy. Warstwy Ogólnego przeznaczenia, Premium i Krytyczne dla działania firmy obsługują nadmiarowość strefową w usłudze Azure SQL DB.
- Konfigurowanie kopii zapasowych bazy danych SQL w celu używania magazynu strefowo nadmiarowego (ZRS) lub magazynu geograficznie nadmiarowego (GZRS).
Blob storage
- Usługa Azure Zone-Redundant Storage (ZRS) replikuje dane synchronicznie w trzech strefach dostępności w regionie. Utwórz konta magazynu magazynu ZRS w warstwie Standardowa lub Standardowa GZRS, aby upewnić się, że dane są replikowane w różnych strefach dostępności.
- Utwórz oddzielne konta magazynu dla wdrożeń, zasobów internetowych i innych danych, aby można było zarządzać kontami i konfigurować je oddzielnie.
Efektywność wydajności
Efektywność wydajności to możliwość skalowania obciążenia w celu zaspokojenia zapotrzebowania użytkowników w wydajny sposób. Aby uzyskać więcej informacji, zobacz Omówienie filaru wydajności.
W poniższych sekcjach omówiono skalowalność kluczowych składników w tej architekturze.
Application Gateway
- Zaimplementuj skalowanie automatyczne dla usługi Application Gateway w celu skalowania w poziomie lub w poziomie w celu spełnienia wymagań.
- Ustaw maksymalną liczbę wystąpień na liczbę większą niż oczekiwano. Opłaty będą naliczane tylko za używane jednostki pojemności.
- Ustaw minimalną liczbę wystąpień, która może obsługiwać małe skoki ruchu. Aby obliczyć minimalną liczbę wystąpień, możesz użyć średniego użycia jednostek obliczeniowych.
- Postępuj zgodnie ze wskazówkami dotyczącymi określania rozmiaru podsieci usługi Application Gateway.
App Service
- Użyj planów w warstwie Standardowa lub nowszej z co najmniej trzema wystąpieniami procesu roboczego w celu zapewnienia wysokiej dostępności.
- Włącz automatyczne skalowanie , aby upewnić się, że możesz skalować w górę i w dół, aby zaspokoić zapotrzebowanie.
- Rozważ otwarcie biletu pomocy technicznej, aby zwiększyć maksymalną liczbę procesów roboczych do dwóch razy większej liczby wystąpień , jeśli usługa App Service stale używa połowy maksymalnej liczby wystąpień. Maksymalna liczba wystąpień domyślnie wynosi do 30 dla planu usługi App Service w warstwie Premium i 10 dla planu w warstwie Standardowa.
- Rozważ wdrożenie wielu sygnatur aplikacji, gdy usługa App Service zacznie osiągać górne limity.
- Wybierz odpowiedni plan usługi aplikacja systemu Azure, który spełnia wymagania dotyczące obciążenia.
- Dodaj usługę Azure CDN do usługi aplikacja systemu Azure, aby obsługiwać zawartość statyczną.
- Rozważ środowisko App Service Environment , jeśli hałaśliwe sąsiedzi są problemem.
SQL Server
Skalowanie zasobów bazy danych jest złożonym tematem poza zakresem tej architektury. Podczas skalowania bazy danych należy wziąć pod uwagę następujące zasoby.
- Dynamiczne skalowanie zasobów bazy danych przy minimalnym przestoju
- Scaling out with Azure SQL Database (Skalowanie w poziomie za pomocą usługi Azure SQL Database)
- Używanie replik tylko do odczytu do odciążania obciążeń zapytań tylko do odczytu
Inne wskazówki dotyczące skalowalności
- Przejrzyj limity subskrypcji i limity przydziału , aby upewnić się, że usługi są skalowane na żądanie.
- Rozważ buforowanie dla następujących rodzajów danych, aby zwiększyć wydajność i skalowalność:
- Częściowo statyczne dane transakcji.
- Stan sesji.
- Dane wyjściowe HTML. Może to być przydatne w aplikacjach renderujących złożone dane wyjściowe HTML.
Zabezpieczenia
Podstawowa architektura usługi App Service koncentruje się na podstawowych zaleceniach dotyczących zabezpieczeń aplikacji internetowej. Zrozumienie sposobu działania szyfrowania i tożsamości w każdej warstwie ma kluczowe znaczenie dla zabezpieczenia obciążenia.
App Service
- Wyłączanie lokalnych metod uwierzytelniania dla wdrożeń witryn FTP i SCM
- Wyłącz zdalne debugowanie.
- Użyj najnowszej wersji protokołu TLS.
- Włącz usługę Microsoft Defender dla usługi App Service.
- Użyj najnowszych wersji obsługiwanych platform, języków programowania, protokołów i struktur.
- Rozważ środowisko App Service Environment , jeśli potrzebujesz wyższej izolacji lub bezpiecznego dostępu do sieci.
Szyfrowanie
Produkcyjna aplikacja internetowa musi szyfrować dane przesyłane przy użyciu protokołu HTTPS. Protokół HTTPS opiera się na protokole Transport Layer Security (TLS) i używa kluczy publicznych i prywatnych do szyfrowania. Należy przechowywać certyfikat (X.509) w usłudze Key Vault i zezwolić usłudze Application Gateway na pobranie klucza prywatnego. W przypadku danych magazynowanych niektóre usługi automatycznie szyfrują dane, a inne umożliwiają dostosowywanie.
Dane przesyłane
W architekturze bazowej dane przesyłane są szyfrowane od użytkownika do aplikacji internetowej w usłudze App Service. W poniższym przepływie pracy opisano sposób działania szyfrowania na wysokim poziomie.
- Użytkownik wysyła żądanie HTTPS do aplikacji internetowej.
- Żądanie HTTPS dociera do bramy aplikacji.
- Brama aplikacji używa certyfikatu (X.509) w usłudze Key Vault do utworzenia bezpiecznego połączenia TLS z przeglądarką internetową użytkownika. Brama aplikacji odszyfrowuje żądanie HTTPS, aby zapora aplikacji internetowej mogła ją sprawdzić.
- Brama aplikacji tworzy połączenie TLS z usługą App Service w celu ponownego zaszyfrowania żądania użytkownika. Usługa App Service zapewnia natywną obsługę protokołu HTTPS, dlatego nie trzeba dodawać certyfikatu do usługi App Service. Brama aplikacji wysyła zaszyfrowany ruch do usługi App Service. Usługa App Service odszyfrowuje ruch, a aplikacja internetowa przetwarza żądanie.
Podczas konfigurowania szyfrowania danych podczas przesyłania danych należy wziąć pod uwagę następujące zalecenia.
- Utwórz lub przekaż certyfikat do usługi Key Vault. Szyfrowanie HTTPS wymaga certyfikatu (X.509). Potrzebujesz certyfikatu z zaufanego urzędu certyfikacji dla domeny niestandardowej.
- Zapisz klucz prywatny do certyfikatu w usłudze Key Vault.
- Postępuj zgodnie ze wskazówkami w temacie Udzielanie aplikacji uprawnień dostępu do magazynu kluczy platformy Azure przy użyciu kontroli dostępu opartej na rolach platformy Azure i tożsamości zarządzanych dla zasobów platformy Azure, aby zapewnić usłudze Application Gateway dostęp do klucza prywatnego certyfikatu. Nie używaj zasad dostępu do usługi Key Vault, aby zapewnić dostęp. Zasady dostępu umożliwiają tylko przyznawanie szerokich uprawnień nie tylko określonym wartościom.
- Włącz kompleksowe szyfrowanie. Usługa App Service to pula zaplecza bramy aplikacji. Podczas konfigurowania ustawienia zaplecza dla puli zaplecza użyj protokołu HTTPS za pośrednictwem portu zaplecza 443.
Dane magazynowane
- Szyfrowanie poufnych danych w usłudze Azure SQL Database przy użyciu przezroczystego szyfrowania danych. Przezroczyste dane szyfrują całą bazę danych, kopie zapasowe i pliki dziennika transakcji oraz nie wymagają żadnych zmian w aplikacji internetowej.
- Zminimalizuj opóźnienie szyfrowania bazy danych. Aby zminimalizować opóźnienie szyfrowania, umieść dane potrzebne do zabezpieczenia we własnej bazie danych i włącz szyfrowanie tylko dla tej bazy danych.
- Omówienie wbudowanej obsługi szyfrowania. Usługa Azure Storage automatycznie szyfruje dane magazynowane przy użyciu szyfrowania po stronie serwera (256-bitowego AES). Usługa Azure Monitor automatycznie szyfruje dane magazynowane przy użyciu kluczy zarządzanych przez firmę Microsoft (MMKs).
Zarządzanie tożsamościami i dostępem
Punkt odniesienia usługi App Service konfiguruje uwierzytelnianie i autoryzację dla tożsamości użytkowników (użytkowników) i tożsamości obciążeń (zasobów platformy Azure) oraz implementuje zasadę najniższych uprawnień.
Tożsamości użytkowników
- Użyj zintegrowanego mechanizmu uwierzytelniania dla usługi App Service ("EasyAuth").. Usługa EasyAuth upraszcza proces integrowania dostawców tożsamości z aplikacją internetową. Obsługuje uwierzytelnianie poza aplikacją internetową, więc nie trzeba wprowadzać znaczących zmian w kodzie.
- Skonfiguruj adres URL odpowiedzi dla domeny niestandardowej. Musisz przekierować aplikację internetową do
https://<application-gateway-endpoint>/.auth/login/<provider>/callback
. Zastąp<application-gateway-endpoint>
ciąg publicznym adresem IP lub niestandardową nazwą domeny skojarzona z bramą aplikacji. Zastąp<provider>
element dostawcą uwierzytelniania, którego używasz, takim jak "aad" dla identyfikatora Entra firmy Microsoft. Możesz użyć dokumentacji usługi Azure Front, aby skonfigurować ten przepływ za pomocą usługi Application Gateway lub skonfigurować usługę Application Gateway.
Tożsamości obciążeń
- Użyj tożsamości zarządzanej dla tożsamości obciążeń. Tożsamość zarządzana eliminuje konieczność zarządzania poświadczeniami uwierzytelniania przez deweloperów.
- Użyj tożsamości zarządzanych przypisanych przez użytkownika. Tożsamość przypisana przez system może spowodować niepowodzenie wdrożeń infrastruktury jako kodu w oparciu o warunki wyścigu i kolejność operacji. Aby uniknąć niektórych z tych scenariuszy błędów wdrażania, można użyć tożsamości zarządzanych przypisanych przez użytkownika. Aby uzyskać więcej informacji, zobacz Tożsamości zarządzane.
Doskonałość operacyjna
Doskonałość operacyjna obejmuje procesy operacyjne, które wdrażają aplikację i działają w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz Omówienie filaru doskonałości operacyjnej.
Wdrożenie podstawowej aplikacji usługi App Service jest zgodne ze wskazówkami w temacie Ciągła integracja/ciągłe wdrażanie dla usługi Azure Web Apps z usługą Azure Pipelines. Oprócz tych wskazówek architektura punktu odniesienia usługi App Services uwzględnia zabezpieczenia sieci aplikacji i konta magazynu wdrożenia. Architektura odmawia publicznego dostępu do usługi App Service. Oznacza to, że nie można wdrożyć z zewnątrz sieci wirtualnej. Punkt odniesienia pokazuje, jak wdrożyć kod aplikacji w sieci wirtualnej przy użyciu własnych agentów wdrażania. Poniższe wskazówki dotyczące wdrażania koncentrują się na wdrażaniu kodu aplikacji i nie wdrażaniu zmian infrastruktury lub bazy danych.
Rysunek 3. Wdrażanie aplikacji usługi aplikacja systemu Azure
Przepływ wdrażania
W ramach potoku wydania potok publikuje żądanie zadania dla własnych agentów w kolejce zadań. Żądanie zadania dotyczy agenta przekazania artefaktu kompilacji pliku zip publikowania na konto usługi Azure Storage.
Własny agent wdrażania pobiera nowe żądanie zadania za pośrednictwem sondowania. Pobiera zadanie i artefakt kompilacji.
Własny agent wdrażania przekazuje plik zip do konta magazynu za pośrednictwem prywatnego punktu końcowego konta magazynu.
Potok będzie kontynuowany, a zarządzany agent pobiera kolejne zadanie. Agent zarządzany wywołuje interfejs wiersza polecenia, aby zaktualizować aplikacjęUstawienia WEBSITE_RUN_FROM_PACKAGE na nazwę nowego pliku zip publikowania dla miejsca przejściowego.
az webapp config appsettings set -g MyResourceGroupName -n MyUniqueApp --slot staging --settings WEBSITE_RUN_FROM_PACKAGE=UriToNewZip
usługa aplikacja systemu Azure pobiera nowy plik zip publikowania z magazynu za pośrednictwem prywatnego punktu końcowego konta magazynu. Wystąpienie przejściowe jest uruchamiane ponownie przy użyciu nowego pakietu, ponieważ WEBSITE_RUN_FROM_PACKAGE został ustawiony na inną nazwę pliku.
Potok jest wznawiany i uruchamia testy weryfikacyjne kompilacji lub czeka na zatwierdzenie. Jeśli testy przejdą lub zatwierdzą, potok zamienia miejsca przejściowe i produkcyjne.
Wskazówki dotyczące wdrażania
Poniżej przedstawiono najważniejsze wskazówki dotyczące wdrażania architektury punktu odniesienia.
- Użyj polecenia uruchom z pakietu , aby uniknąć konfliktów wdrażania. Po uruchomieniu aplikacji bezpośrednio z pakietu w usłudze aplikacja systemu Azure pliki w pakiecie nie są kopiowane do katalogu wwwroot. Zamiast tego sam pakiet ZIP jest instalowany bezpośrednio jako katalog wwwroot tylko do odczytu. Eliminuje to konflikty blokady plików między wdrożeniem a środowiskiem uruchomieniowym i zapewnia uruchamianie tylko w pełni wdrożonych aplikacji w dowolnym momencie
- Dołącz numery wersji do wdrożonych plików zip pakietu.
WEBSITE_RUN_FROM_PACKAGE
Zaktualizowanie ustawienia aplikacji do pakietu wdrożeniowego przy użyciu innej nazwy pliku powoduje, że usługi App Services automatycznie pobierają nową wersję i ponownie uruchamiają usługę. - Użyj miejsc wdrożenia na potrzeby odpornych wdrożeń kodu.
- Rozważ użycie kombinacji zarządzanych i własnych agentów.
- Użyj własnych agentów , aby przekazać plik zip pakietu do konta magazynu za pośrednictwem prywatnego punktu końcowego. Agent inicjuje komunikację z potokiem za pośrednictwem sondowania, więc nie jest wymagane otwarcie sieci dla wywołania przychodzącego.
- Użyj agentów zarządzanych dla innych zadań w potoku.
- Automatyzowanie wdrożeń infrastruktury przy użyciu infrastruktury jako kodu (IaC).
- Stale weryfikuje obciążenie, aby przetestować wydajność i odporność całego rozwiązania przy użyciu usług, takich jak testowanie obciążenia platformy Azure i usługa Azure Chaos Studio.
Konfigurowanie
Aplikacje wymagają zarówno wartości konfiguracji, jak i wpisów tajnych. Skorzystaj z poniższych wskazówek dotyczących zarządzania konfiguracjami i wpisami tajnymi.
- Nigdy nie sprawdzaj wpisów tajnych, takich jak hasła lub klucze dostępu do kontroli źródła.
- Przechowywanie wpisów tajnych za pomocą usługi Azure Key Vault .
- Użyj konfiguracji usługi App Service dla konfiguracji aplikacji. Jeśli musisz zewnętrznie skonfigurować konfigurację z konfiguracji aplikacji lub wymagać obsługi flag funkcji, rozważ użycie aplikacja systemu Azure Configuration.
- Użyj odwołań usługi Key Vault w konfiguracji usługi App Service, aby bezpiecznie uwidocznić wpisy tajne w aplikacji.
- Utwórz ustawienia aplikacji, które trzymają się miejsca i nie są zamieniane, jeśli potrzebujesz różnych ustawień produkcyjnych i przejściowych. Podczas zamiany miejsca wdrożenia ustawienia aplikacji są domyślnie zamieniane.
- Ustaw lokalne zmienne środowiskowe na potrzeby programowania lokalnego lub korzystaj z funkcji platformy aplikacji. Konfiguracja usługi App Services uwidacznia ustawienia aplikacji jako zmienne środowiskowe. Program Visual Studio umożliwia na przykład ustawianie zmiennych środowiskowych w profilach uruchamiania. Umożliwia również używanie ustawień aplikacji i wpisów tajnych użytkownika do przechowywania lokalnych ustawień aplikacji i wpisów tajnych.
Monitorowanie
Monitorowanie to zbieranie i analiza danych z systemów IT. Celem monitorowania jest obserwowanie na wielu warstwach w celu śledzenia kondycji i zabezpieczeń aplikacji internetowej. Obserwowanie jest kluczowym aspektem architektury usługi App Service bazowej.
Aby monitorować aplikację internetową, musisz zbierać i analizować metryki i dzienniki z kodu aplikacji, infrastruktury (środowiska uruchomieniowego) i platformy (zasobów platformy Azure). Aby uzyskać więcej informacji, zobacz Dziennik aktywności platformy Azure, dzienniki zasobów platformy Azure i dzienniki aplikacji.
Monitorowanie platformy
Monitorowanie platformy to zbieranie danych z usług platformy Azure w architekturze. Zapoznaj się z poniższymi wskazówkami dotyczącymi monitorowania platformy.
Dodaj ustawienie diagnostyczne dla każdego zasobu platformy Azure. Każda usługa platformy Azure ma inny zestaw dzienników i metryk, które można przechwycić. Skorzystaj z poniższej tabeli, aby ustalić metryki i dzienniki, które chcesz zebrać.
Zasób platformy Azure Metryki i opisy dzienników Application Gateway Opisy metryk i dzienników usługi Application Gateway Web Application Firewall Metryki i opisy dzienników zapory aplikacji internetowej App Service Opisy metryk i dzienników usługi App Service Azure SQL Database Opis metryk i dzienników usługi Azure SQL Database CosmosDB Opisy metryk i dzienników usługi Azure Cosmos DB Key Vault Opisy metryk i dzienników usługi Key Vault Blob Storage Opisy metryk i dzienników usługi Azure Blob Storage Szczegółowe dane dotyczące aplikacji Opisy metryk i dzienników usługi Application Insights Publiczny adres IP Metryki i opisy dzienników publicznego adresu IP Omówienie kosztów zbierania metryk i dzienników. Ogólnie rzecz biorąc, tym więcej metryk i dzienników zbierasz, tym więcej kosztuje. Aby uzyskać więcej informacji, zobacz Obliczenia kosztów i opcje usługi Log Analytics oraz Cennik obszaru roboczego usługi Log Analytics.
Tworzenie alertów Należy utworzyć alerty dla wszystkich zasobów platformy Azure w architekturze i skonfigurować akcje w celu rozwiązania problemów. Wybierz typowe i zalecane reguły alertów, aby rozpocząć od i zmodyfikować je w miarę potrzeb. Aby uzyskać więcej informacji, zobacz:
Application Gateway
Usługa Application Gateway monitoruje kondycję zasobów w puli zaplecza. Użyj dzienników dostępu usługi Application Gateway, aby zebrać informacje, takie jak sygnatura czasowa, kod odpowiedzi HTTP i ścieżka adresu URL. Aby uzyskać więcej informacji, zobacz Domyślna sonda kondycji usługi Application Gateway oraz kondycja zaplecza i dzienniki diagnostyczne.
App Service
Usługa App Service ma wbudowane i zintegrowane narzędzia do monitorowania, które należy włączyć w celu zwiększenia możliwości obserwacji. Jeśli aplikacja internetowa ma już funkcje telemetrii i monitorowania ("instrumentacja w procesie"), powinna nadal działać w usłudze App Service.
- Włącz instrumentację automatyczną. Usługa App Service ma rozszerzenie instrumentacji, które można włączyć bez zmian w kodzie. Uzyskasz widoczność monitorowania wydajności aplikacji (APM). Aby uzyskać więcej informacji, zobacz Monitorowanie wydajności usługi aplikacja systemu Azure.
- Włącz śledzenie rozproszone. Automatyczna instrumentacja umożliwia monitorowanie rozproszonych systemów w chmurze za pośrednictwem śledzenia rozproszonego i profilera wydajności.
- Użyj instrumentacji opartej na kodzie na potrzeby niestandardowej telemetrii. usługa aplikacja systemu Azure Insights obsługuje również instrumentację opartą na kodzie na potrzeby telemetrii aplikacji niestandardowych. Dodaj zestaw SDK usługi Application Insights do kodu i użyj interfejsu API usługi Application Insights.
- Włącz dzienniki usługi App Service. Platforma App Service obsługuje cztery dodatkowe dzienniki, które należy włączyć w celu obsługi rozwiązywania problemów. Te dzienniki to dzienniki aplikacji, dzienniki serwera internetowego, szczegółowe komunikaty o błędach i śledzenie żądań niepomyślnych.
- Użyj rejestrowania strukturalnego. Dodaj bibliotekę rejestrowania strukturalnego do kodu aplikacji. Zaktualizuj kod, aby używał par klucz-wartość i włącz dzienniki aplikacji w usłudze App Service, aby przechowywać te dzienniki w obszarze roboczym usługi Log Analytics.
- Włącz sprawdzanie kondycji usługi App Service. Sprawdzanie kondycji przekierowuje żądania z dala od wystąpień w złej kondycji i zastępuje wystąpienia w złej kondycji. Plan usługi App Service musi używać co najmniej dwóch wystąpień, aby testy kondycji działały.
baza danych
- Szczegółowe informacje o bazie danych użytkowników. W przypadku baz danych Azure SQL Database należy skonfigurować usługę SQL Insights w usłudze Azure Monitor. Usługa Database Insights używa dynamicznych widoków zarządzania, aby uwidocznić dane potrzebne do monitorowania kondycji, diagnozowania problemów i dostrajania wydajności. Aby uzyskać więcej informacji, zobacz Monitorowanie usługi Azure SQL Database za pomocą usługi Azure Monitor.
- Jeśli twoja architektura obejmuje usługę Cosmos DB, nie musisz włączać ani konfigurować żadnych elementów w celu korzystania ze szczegółowych informacji usługi Cosmos DB.
Ład korporacyjny
Aplikacje internetowe korzystają z usługi Azure Policy, wymuszając decyzje dotyczące architektury i zabezpieczeń. Usługa Azure Policy może uniemożliwić (1) wdrożenie (odmowę) lub (2) łatwe wykrywanie (inspekcja) dryfu konfiguracji z preferowanego żądanego stanu. Ułatwia to przechwytywanie wdrożeń infrastruktury jako kodu (IaC) lub zmian w witrynie Azure Portal, które odbiegają od uzgodnionej architektury. Wszystkie zasoby należy umieścić w architekturze w obszarze ład usługi Azure Policy. Użyj wbudowanych zasad lub inicjatyw zasad, jeśli to możliwe, aby wymusić podstawową topologię sieci, funkcje usług, zabezpieczenia i decyzje dotyczące monitorowania, na przykład:
- Usługa App Service powinna wyłączyć dostęp do sieci publicznej
- Usługa App Service powinna używać integracji z siecią wirtualną
- Usługa App Service powinna używać usługi Azure Private Link do nawiązywania połączenia z usługami PaaS
- Usługa App Service powinna mieć wyłączone lokalne metody uwierzytelniania dla wdrożeń witryn FTP i SCM
- Usługa App Service powinna mieć wyłączone zdalne debugowanie
- Aplikacje usługi App Service powinny używać najnowszej wersji protokołu TLS
- Usługa Microsoft Defender dla usługi App Service powinna być włączona
- Zapora aplikacji internetowej (WAF) powinna być włączona dla usługi Application Gateway
Zobacz więcej wbudowanych zasad dla kluczowych usług, takich jak Application Gateway i składniki sieciowe, App Service, Key Vault i Monitorowanie. Istnieje możliwość utworzenia niestandardowych zasad lub użycia zasad społeczności (takich jak ze stref docelowych platformy Azure), jeśli wbudowane zasady nie spełniają w pełni Twoich potrzeb. Preferuj wbudowane zasady, gdy są dostępne.