Upravit

Sdílet prostřednictvím


Standardní vysoce dostupná zónově redundantní webová aplikace

Azure App Service
Azure Application Gateway
Azure Storage
Azure SQL Database
Azure Private Link
Azure Virtual Network
Azure Monitor

Tato základní architektura je založená na architektuře základní webové aplikace a rozšiřuje ji o podrobné pokyny k návrhu zabezpečené, zónově redundantní a vysoce dostupné webové aplikace v Azure. Architektura zveřejňuje veřejný koncový bod prostřednictvím brány Aplikace Azure lication Gateway s firewallem webových aplikací. Směruje požadavky na službu Aplikace Azure prostřednictvím služby Private Link. Aplikace App Service používá integraci virtuální sítě a službu Private Link k zabezpečené komunikaci se službami Azure PaaS, jako je Azure Key Vault a Azure SQL Database.

Důležité

Logo GitHubu Pokyny jsou podporovány ukázkovou implementací , která představuje základní implementaci služby App Service v Azure. Tuto implementaci můžete použít jako základ pro další vývoj řešení v prvním kroku k produkčnímu prostředí.

Architektura

Diagram znázorňující základní architekturu služby App Service s zónovou redundancí a vysokou dostupností

Obrázek 1: Architektura služby Aplikace Azure podle směrného plánu

Stáhněte si soubor aplikace Visio s touto architekturou.

Komponenty

Mnoho komponent této architektury je stejné jako základní architektura webových aplikací. Následující seznam zvýrazňuje pouze změny základní architektury.

  • Application Gateway je nástroj pro vyrovnávání zatížení vrstvy 7 (HTTP/S) a správce webového provozu. Používá směrování založené na cestě URL k distribuci příchozího provozu mezi zóny dostupnosti a šifrování přesměrování zátěže, aby se zlepšil výkon aplikace.
  • Firewall webových aplikací (WAF) je cloudová nativní služba, která chrání webové aplikace před běžnými zneužitími, jako je injektáž SQL a skriptování mezi weby. WAF poskytuje přehled o provozu do a z vaší webové aplikace a umožňuje monitorovat a zabezpečit aplikaci.
  • Azure Key Vault je služba, která bezpečně ukládá a spravuje tajné kódy, šifrovací klíče a certifikáty. Centralizuje správu citlivých informací.
  • Azure Virtual Network je služba, která umožňuje vytvářet izolované a zabezpečené privátní virtuální sítě v Azure. Pro webovou aplikaci ve službě App Service potřebujete podsíť virtuální sítě, která bude používat privátní koncové body pro zabezpečenou síťovou komunikaci mezi prostředky.
  • Private Link umožňuje klientům přistupovat ke službám Azure jako služby jako služby (PaaS) přímo z privátních virtuálních sítí bez použití přidělování veřejných IP adres.
  • Azure DNS je hostitelská služba pro domény DNS, která poskytuje překlad názvů pomocí infrastruktury Microsoft Azure. Privátní DNS zóny poskytují způsob, jak mapovat plně kvalifikovaný název domény (FQDN) služby na IP adresu privátního koncového bodu.

Sítě

Zabezpečení sítě je základem základní architektury služby App Services (viz obrázek 2). Z vysoké úrovně zajišťuje síťová architektura následující:

  1. Jeden zabezpečený vstupní bod pro klientský provoz
  2. Síťový provoz se filtruje.
  3. Přenášená data se šifrují kompletním šifrováním tls.
  4. Exfiltrace dat se minimalizuje tím, že provoz v Azure zachováte pomocí služby Private Link.
  5. Síťové prostředky jsou logicky seskupené a izolované od sebe prostřednictvím segmentace sítě.

Toky sítě

Diagram znázorňující základní síťovou architekturu služby App Service

Obrázek 2: Síťová architektura základní aplikace služby Aplikace Azure

Následuje popis příchozího toku internetového provozu do instance služby App Service a tok ze služby App Service do služeb Azure.

Příchozí tok

  1. Uživatel vydá požadavek na veřejnou IP adresu služby Application Gateway.
  2. Vyhodnocují se pravidla WAF. Pravidla WAF pozitivně ovlivňují spolehlivost systému tím, že chrání před různými útoky, jako jsou skriptování mezi weby (XSS) a injektáž SQL. Aplikace Azure lication Gateway vrátí žadateli chybu, pokud dojde k porušení pravidla WAF a zpracování se zastaví. Pokud nejsou porušena žádná pravidla WAF, služba Application Gateway směruje požadavek do back-endového fondu, což je v tomto případě výchozí doména služby App Service.
  3. Privátní zóna privatelink.azurewebsites.net DNS je propojená s virtuální sítí. Zóna DNS obsahuje záznam A, který mapuje výchozí doménu služby App Service na privátní IP adresu privátního koncového bodu služby App Service. Tato propojená privátní zóna DNS umožňuje Službě Azure DNS přeložit výchozí doménu na IP adresu privátního koncového bodu.
  4. Požadavek se směruje do instance služby App Service prostřednictvím privátního koncového bodu.

Tok služeb App Service do Azure PaaS

  1. App Service odešle požadavek na název DNS požadované služby Azure. Žádost může být ve službě Azure Key Vault, aby získala tajný kód, Azure Storage a získala soubor ZIP pro publikování, Azure SQL Database nebo jakoukoli jinou službu Azure, která podporuje službu Private Link. Funkce integrace virtuální sítě služby App Service směruje požadavek přes virtuální síť.
  2. Podobně jako krok 3 v příchozím toku má propojená privátní zóna DNS záznam A, který mapuje doménu služby Azure na privátní IP adresu privátního koncového bodu. Tato propojená privátní zóna DNS umožňuje Službě Azure DNS přeložit doménu na IP adresu privátního koncového bodu služby.
  3. Požadavek se směruje do služby prostřednictvím privátního koncového bodu.

Příchozí přenos dat do App Services

Application Gateway je regionální prostředek, který splňuje požadavky této základní architektury. Application Gateway je škálovatelný, regionální nástroj pro vyrovnávání zatížení vrstvy 7, který podporuje funkce, jako je firewall webových aplikací a přesměrování zpracování PROTOKOLU TLS. Při implementaci služby Application Gateway pro příchozí přenos dat do Aplikace Azure Services zvažte následující body.

  • Nasaďte Službu Application Gateway a nakonfigurujte zásady WAF pomocí sady pravidel spravovaných Microsoftem. Pomocí režimu prevence můžete zmírnit webové útoky, které by mohly způsobit nedostupnost služby původu (App Service v architektuře).
  • Implementujte kompletní šifrování TLS.
  • Pomocí privátních koncových bodů implementujte příchozí privátní přístup ke službě App Service.
  • Zvažte implementaci automatického škálování pro službu Application Gateway, aby se snadno přizpůsobila dynamickým tokům provozu.
  • Zvažte použití minimálního počtu instancí škálování, který není menší než tři, a vždy používejte všechny zóny dostupnosti, které vaše oblast podporuje. I když je služba Application Gateway nasazená vysoce dostupným způsobem, i pro jednu instanci škálování, vytvoření nové instance při selhání může trvat až sedm minut. Nasazení více instancí napříč Zóny dostupnosti pomáhá zajistit, že při selhání je instance spuštěná při vytváření nové instance.
  • Zakažte veřejný přístup k síti ve službě App Service, abyste zajistili izolaci sítě. V Bicep se to provádí nastavením publicNetworkAccess: 'Disabled' vlastností/siteConfig.

Tok ze služeb App Services do služeb Azure

Tato architektura používá integraci virtuální sítě pro službu App Service, konkrétně ke směrování provozu do privátních koncových bodů přes virtuální síť. Základní architektura neumožňuje směrování veškerého provozu vynutit veškerý odchozí provoz přes virtuální síť, pouze interní provoz, jako je provoz vázaný na privátní koncové body.

Služby Azure, které nevyžadují přístup z veřejného internetu, by měly mít povolené privátní koncové body a veřejné koncové body jsou zakázané. Privátní koncové body se používají v celé této architektuře ke zlepšení zabezpečení tím, že službě App Service umožní připojení ke službám Private Link přímo z vaší privátní virtuální sítě bez použití přidělování veřejných IP adres.

V této architektuře mají všechny služby Azure SQL Database, Azure Storage a Key Vault zakázané veřejné koncové body. Brány firewall služeb Azure se používají jenom k povolení provozu z jiných autorizovaných služeb Azure. Další služby Azure byste měli nakonfigurovat s privátními koncovými body, jako jsou Azure Cosmos DB a Azure Redis Cache. V této architektuře Azure Monitor nepoužívá privátní koncový bod, ale může.

Základní architektura implementuje privátní zónu DNS pro každou službu. Privátní zóna DNS obsahuje záznam A, který se mapuje mezi plně kvalifikovaným názvem domény služby a privátní IP adresou privátního koncového bodu. Zóny jsou propojené s virtuální sítí. Privátní DNS skupin zón se ujistěte, že se záznamy DNS privátního propojení automaticky vytvářejí a aktualizují.

Při implementaci integrace virtuální sítě a privátních koncových bodů zvažte následující body.

Segmentace a zabezpečení virtuální sítě

Síť v této architektuře má samostatné podsítě pro službu Application Gateway, integrační komponenty služby App Service a privátní koncové body. Každá podsíť má skupinu zabezpečení sítě, která omezuje příchozí i odchozí provoz pro tyto podsítě jenom na to, co je potřeba. Následující tabulka ukazuje zjednodušené zobrazení pravidel NSG, která směrný plán přidá do každé podsítě. Tabulka poskytuje název a funkci pravidla.

Podsíť Příchozí Odchozí
snet-AppGateway AppGw.In.Allow.ControlPlane: Povolit přístup k rovině řízení příchozích dat

AppGw.In.Allow443.Internet: Povolit příchozí přístup přes internet HTTPS
AppGw.Out.Allow.AppServices: Povolit odchozí přístup k AppServicesSubnet

AppGw.Out.Allow.PrivateEndpoints: Povolit odchozí přístup k PrivateEndpointsSubnet

AppPlan.Out.Allow.AzureMonitor: Povolení odchozího přístupu ke službě Azure Monitor
snet-PrivateEndpoints Výchozí pravidla: Povolit příchozí provoz z virtuální sítě Výchozí pravidla: Povolení odchozích přenosů do virtuální sítě
snet-AppService Výchozí pravidla: Povolit příchozí provoz z virtuální sítě AppPlan.Out.Allow.PrivateEndpoints: Povolit odchozí přístup k PrivateEndpointsSubnet

AppPlan.Out.Allow.AzureMonitor: Povolení odchozího přístupu ke službě Azure Monitor

Při implementaci segmentace a zabezpečení virtuální sítě zvažte následující body.

  • Povolte ochranu před útoky DDoS pro virtuální síť s podsítí, která je součástí aplikační brány s veřejnou IP adresou.
  • Pokud je to možné, přidejte skupinu zabezpečení sítě do každé podsítě. Měli byste použít nejtužší pravidla, která umožňují plnou funkčnost řešení.
  • Používejte skupiny zabezpečení aplikací. Skupiny zabezpečení aplikací umožňují seskupit skupiny zabezpečení sítě, což usnadňuje vytváření pravidel pro složitá prostředí.

Příkladem schématu virtuální podsítě může být:

Typ Název Rozsah adres
Virtual Network Předpona adresy 10.0.0.0/16
Podsíť GatewaySubnet 10.0.1.0/24
Podsíť AppServicesSubnet 10.0.0.0/24
Podsíť PrivateEndpointsSubnet 10.0.2.0/27
Podsíť AgentsSubject 10.0.2.32/27

Referenční informace o implementaci Azure-Samples\app-service-baseline-implementation

Důležité informace

Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které je možné použít ke zlepšení kvality úlohy. Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.

Spolehlivost

Spolehlivost zajišťuje, že vaše aplikace může splňovat závazky, které uděláte pro vaše zákazníky. Další informace najdete v tématu Přehled pilíře spolehlivosti.

Základní architektura služby App Services se zaměřuje na zónovou redundanci klíčových regionálních služeb. Zóny dostupnosti jsou fyzicky oddělená umístění v rámci oblasti. Poskytují zónovou redundanci pro podpůrné služby při nasazení dvou nebo více instancí v podpůrných oblastech. Pokud dojde k výpadku jedné zóny, ostatní zóny můžou být stále nedostupné.

Architektura také zajišťuje dostatek instancí služeb Azure pro splnění poptávky. Následující části poskytují pokyny ke spolehlivosti klíčových služeb v architektuře. Díky tomu zóny dostupnosti pomáhají dosáhnout spolehlivosti tím, že poskytují vysokou dostupnost a odolnost proti chybám.

Application Gateway

Nasaďte bránu Aplikace Azure lication v2 v zónově redundantní konfiguraci. Pokud dojde k selhání, zvažte použití minimálního počtu instancí škálování, který nesmí být menší než tři, abyste se vyhnuli 6 až sedmiminutové době spuštění instance služby Application Gateway.

App Services

  • Nasaďte minimálně tři instance služby App Services s podporou zóny dostupnosti.
  • Implementujte do svých aplikací koncové body kontroly stavu a nakonfigurujte funkci kontroly Stav služby aplikace tak, aby přesměrovává požadavky mimo instance, které nejsou v pořádku. Další informace o kontrole stavu služby App Service najdete v tématu Monitorování instancí služby App Service pomocí kontroly stavu. Další informace o implementaci koncových bodů kontroly stavu v aplikacích ASP.NET najdete v tématu Kontroly stavu v ASP.NET Core.
  • Kapacita nadměrného zřízení, aby mohla zpracovávat selhání zóny.

SQL Database

Blob Storage

  • Zónově redundantní úložiště Azure (ZRS) replikuje vaše data synchronně napříč třemi zónami dostupnosti v dané oblasti. Vytvořte účty úložiště Standard ZRS nebo Standard GZRS, abyste zajistili, že se data replikují napříč zónami dostupnosti.
  • Vytvořte samostatné účty úložiště pro nasazení, webové prostředky a další data, abyste mohli spravovat a konfigurovat účty samostatně.

Efektivita výkonu

Efektivita výkonu je schopnost úlohy škálovat se tak, aby efektivním způsobem splňovala požadavky, které na ni kladou uživatelé. Další informace najdete v tématu Přehled pilíře efektivity výkonu.

V následujících částech najdete informace o škálovatelnosti klíčových komponent v této architektuře.

Application Gateway

  • Implementujte automatické škálování pro službu Application Gateway, aby se škálovaly na více nebo více instancí, aby splňovaly poptávku.
  • Nastavte maximální počet instancí na číslo vyšší, než jste očekávali. Za využité jednotky kapacity se vám budou účtovat jenom poplatky.
  • Nastavte minimální počet instancí, který dokáže zpracovat malé špičky v provozu. K výpočtu minimálního počtu instancí můžete použít průměrné využití výpočetních jednotek.
  • Postupujte podle pokynů k určení velikosti podsítě služby Application Gateway.

App Service

SQL Server

Škálování databázových prostředků je komplexní téma mimo rozsah této architektury. Při škálování databáze zvažte následující prostředky:

Další pokyny ke škálovatelnosti

  • Zkontrolujte limity a kvóty předplatného a ujistěte se, že se služby škáluje na vyžádání.
  • Pokud chcete zvýšit výkon a škálovatelnost, zvažte ukládání do mezipaměti pro následující typy dat:
    • Částečně statická data transakcí.
    • Stav relace.
    • Výstup ve formátu HTML. To může být užitečné u aplikací, které vykreslují složité HTML výstupy.

Zabezpečení

Základní architektura služby App Service se zaměřuje na základní doporučení zabezpečení pro vaši webovou aplikaci. Pochopení toho, jak šifrování a identita fungují v každé vrstvě, je důležité pro zabezpečení úloh.

App Service

  • Zakázání místních metod ověřování pro nasazení serveru FTP a SCM
  • Vypněte vzdálené ladění.
  • Použijte nejnovější verzi protokolu TLS.
  • Povolte Microsoft Defender for App Service.
  • Používejte nejnovější verze podporovaných platforem, programovacích jazyků, protokolů a architektur.
  • Pokud potřebujete vyšší izolaci nebo zabezpečený přístup k síti, zvažte službu App Service Environment .

Šifrování

Produkční webová aplikace potřebuje šifrovat přenášená data pomocí protokolu HTTPS. Protokol HTTPS využívá protokol TLS (Transport Layer Security) a k šifrování používá veřejné a privátní klíče. Musíte uložit certifikát (X.509) ve službě Key Vault a povolit službě Application Gateway načtení privátního klíče. U neaktivních uložených dat některé služby automaticky šifrují data a jiné umožňují přizpůsobení.

Přenášená data

V základní architektuře se přenášená data od uživatele do webové aplikace ve službě App Service šifrují. Následující pracovní postup popisuje, jak funguje šifrování na vysoké úrovni.

Diagram znázorňující základní tok šifrování služby App Service

  1. Uživatel odešle do webové aplikace požadavek HTTPS.
  2. Požadavek HTTPS dosáhne aplikační brány.
  3. Aplikační brána používá ve službě Key Vault certifikát (X.509) k vytvoření zabezpečeného připojení TLS s webovým prohlížečem uživatele. Aplikační brána dešifruje požadavek HTTPS, aby ji firewall webových aplikací mohl zkontrolovat.
  4. Aplikační brána vytvoří připojení TLS se službou App Service k opětovnému zašifrování žádosti uživatele. App Service poskytuje nativní podporu protokolu HTTPS, takže do služby App Service nemusíte přidávat certifikát. Aplikační brána odesílá šifrovaný provoz do služby App Service. App Service dešifruje provoz a webová aplikace požadavek zpracuje.

Při konfiguraci šifrování přenášených dat zvažte následující doporučení.

  • Vytvořte nebo nahrajte certifikát do služby Key Vault. Šifrování HTTPS vyžaduje certifikát (X.509). Pro vlastní doménu potřebujete certifikát od důvěryhodné certifikační autority.
  • Uložte privátní klíč do certifikátu ve službě Key Vault.
  • Postupujte podle pokynů v části Udělení oprávnění aplikacím pro přístup k trezoru klíčů Azure pomocí Azure RBAC a spravovaných identit pro prostředky Azure a poskytněte službě Application Gateway přístup k privátnímu klíči certifikátu. Nepoužívejte zásady přístupu ke službě Key Vault k poskytování přístupu. Zásady přístupu umožňují udělit široká oprávnění nejen konkrétním hodnotám.
  • Povolte koncové šifrování. App Service je back-endový fond služby Application Gateway. Při konfiguraci nastavení back-endu pro back-endový fond použijte protokol HTTPS přes back-endový port 443.
Neaktivní uložená data
  • Šifrování citlivých dat ve službě Azure SQL Database pomocí transparentního šifrování dat Transparentní data šifrují celou databázi, zálohy a soubory transakčních protokolů a nevyžaduje žádné změny webové aplikace.
  • Minimalizujte latenci šifrování databáze. Pokud chcete minimalizovat latenci šifrování, umístěte data, která potřebujete zabezpečit, do vlastní databáze a povolte šifrování pouze pro tuto databázi.
  • Seznamte se s integrovanou podporou šifrování. Azure Storage automaticky šifruje neaktivní uložená data pomocí šifrování na straně serveru (256bitová verze AES). Azure Monitor automaticky šifruje neaktivní uložená data pomocí klíčů spravovaných Microsoftem (MMK).

Správa identit a přístupu

Standardní hodnoty služby App Service konfigurují ověřování a autorizaci pro identity uživatelů (uživatele) a identity úloh (prostředky Azure) a implementují princip nejnižšího oprávnění.

Identity uživatelů
  • Použijte integrovaný mechanismus ověřování pro Službu App Service ("EasyAuth"). EasyAuth zjednodušuje proces integrace zprostředkovatelů identity do webové aplikace. Zpracovává ověřování mimo vaši webovou aplikaci, takže nemusíte provádět významné změny kódu.
  • Nakonfigurujte adresu URL odpovědi pro vlastní doménu. Webovou aplikaci musíte přesměrovat na https://<application-gateway-endpoint>/.auth/login/<provider>/callback. Nahraďte <application-gateway-endpoint> veřejnou IP adresu nebo vlastní název domény přidružený k vaší aplikační bráně. Nahraďte <provider> zprostředkovatelem ověřování, který používáte, například "aad" pro ID Microsoft Entra. K nastavení tohoto toku pomocí služby Application Gateway nebo nastavení služby Application Gateway můžete použít dokumentaci ke službě Azure Front.
Identity úloh
  • Používejte spravovanou identitu pro identity úloh. Spravovaná identita eliminuje potřebu vývojářů spravovat přihlašovací údaje pro ověřování.
  • Použijte spravované identity přiřazené uživatelem. Identita přiřazená systémem může způsobit selhání nasazení infrastruktury jako kódu na základě podmínek časování a pořadí operací. Můžete použít spravované identity přiřazené uživatelem, abyste se vyhnuli některým z těchto scénářů chyb nasazení. Další informace najdete v tématu Spravované identity.

Provozní dokonalost

Efektivita provozu zahrnuje provozní procesy, které nasazují aplikaci a udržují ji spuštěnou v produkčním prostředí. Další informace najdete v tématu Přehled pilíře efektivity provozu.

Nasazení pro základní aplikaci App Service se řídí pokyny v CI/CD pro Azure Web Apps se službou Azure Pipelines. Kromě pokynů bere základní architektura služby App Services v úvahu, že aplikace a účet úložiště nasazení jsou zabezpečené v síti. Architektura zakazuje veřejný přístup ke službě App Service. To znamená, že nemůžete nasadit mimo virtuální síť. Směrný plán ukazuje, jak nasadit kód aplikace ve virtuální síti pomocí agentů nasazení v místním prostředí. Následující pokyny k nasazení se zaměřují na nasazení kódu aplikace a nenasazování změn infrastruktury nebo databáze.

Diagram znázorňující základní architekturu nasazení služby App Service

Obrázek 3: Nasazení aplikací služby Aplikace Azure Service

Tok nasazení

  1. V rámci kanálu verze kanál publikuje žádost o úlohu pro agenty v místním prostředí ve frontě úloh. Žádost o úlohu je, aby agent nahrál artefakt sestavení souboru ZIP publikování do účtu úložiště Azure.

  2. Agent nasazení v místním prostředí převezme novou žádost o úlohu prostřednictvím dotazování. Stáhne úlohu a artefakt sestavení.

  3. Agent nasazení v místním prostředí nahraje soubor ZIP do účtu úložiště prostřednictvím privátního koncového bodu účtu úložiště.

  4. Kanál pokračuje a spravovaný agent převezme následnou úlohu. Spravovaný agent volá rozhraní příkazového řádku pro aktualizaci WEBSITE_RUN_FROM_PACKAGE appSetting na název nového souboru ZIP pro přípravný slot.

    az webapp config appsettings set -g MyResourceGroupName -n MyUniqueApp --slot staging --settings WEBSITE_RUN_FROM_PACKAGE=UriToNewZip
    
  5. Aplikace Azure Služba stáhne nový soubor ZIP pro publikování z úložiště prostřednictvím privátního koncového bodu účtu úložiště. Přípravná instance se restartuje s novým balíčkem, protože WEBSITE_RUN_FROM_PACKAGE byla nastavena na jiný název souboru.

  6. Kanál se obnoví a spustí všechny orientační testy nebo počká na schválení. Pokud jsou testy úspěšné nebo schváleny, kanál prohodí přípravné a produkční sloty.

Pokyny pro nasazení

Následující informace zvýrazňují klíčové pokyny k nasazení základní architektury.

  • Pomocí příkazu Spustit z balíčku se vyhnete konfliktům nasazení. Když aplikaci spustíte přímo z balíčku ve službě Aplikace Azure Service, soubory v balíčku se do adresáře wwwroot nekopírují. Místo toho se samotný balíček ZIP připojí přímo jako adresář wwwroot jen pro čtení. Tím se eliminují konflikty zámků souborů mezi nasazením a modulem runtime a zajišťuje, že jsou spuštěné jenom plně nasazené aplikace.
  • Do nasazených souborů ZIP balíčku zahrňte čísla verzí. WEBSITE_RUN_FROM_PACKAGE Aktualizace appSetting na balíček nasazení s jiným názvem souboru způsobí, že App Services automaticky vyzvedne novou verzi a restartuje službu.
  • Použijte sloty nasazení pro odolná nasazení kódu.
  • Zvažte použití kombinace spravovaných a hostovaných agentů.
  • Automatizace nasazení infrastruktury pomocí infrastruktury jako kódu (IaC)
  • Nepřetržitě ověřte úlohu a otestujte výkon a odolnost celého řešení pomocí služeb, jako je Azure Load Testing a Azure Chaos Studio.

Konfigurace

Aplikace vyžadují hodnoty konfigurace i tajné kódy. Při konfiguraci a správě tajných kódů použijte následující doprovodné materiály.

  • Nikdy nekontrolujte tajné kódy, jako jsou hesla nebo přístupové klíče, do správy zdrojového kódu.
  • K ukládání tajných kódů použijte Azure Key Vault .
  • Pro konfiguraci aplikace použijte konfiguraci služby App Service. Pokud potřebujete externalizovat konfiguraci z konfigurace aplikace nebo vyžadovat podporu příznaku funkce, zvažte použití Aplikace Azure Konfigurace.
  • Pomocí odkazů služby Key Vault v konfiguraci služby App Service můžete bezpečně zveřejnit tajné kódy ve vaší aplikaci.
  • Vytvořte nastavení aplikace, která se budou držet slotu, a pokud potřebujete jiná produkční a přípravná nastavení, neprohodí se. Když přepnete slot nasazení, nastavení aplikace se ve výchozím nastavení přepnou.
  • Nastavte místní proměnné prostředí pro místní vývoj nebo využijte funkce aplikační platformy. Konfigurace služby App Services zveřejňuje nastavení aplikace jako proměnné prostředí. Visual Studio například umožňuje nastavit proměnné prostředí ve spouštěcích profilech. Umožňuje také používat nastavení aplikací a tajné kódy uživatelů k ukládání nastavení místních aplikací a tajných kódů.

Sledování

Monitorování je shromažďování a analýza dat z IT systémů. Cílem monitorování je pozorovatelnost ve více vrstvách ke sledování stavu a zabezpečení webové aplikace. Pozorovatelnost je klíčovou vlastností základní architektury služby App Service.

Pokud chcete monitorovat webovou aplikaci, musíte shromažďovat a analyzovat metriky a protokoly z kódu aplikace, infrastruktury (modulu runtime) a platformy (prostředků Azure). Další informace najdete v protokolu aktivit Azure, protokolech prostředků Azure a protokolech aplikací.

Monitorování platformy

Monitorování platformy je shromažďování dat ze služeb Azure ve vaší architektuře. Zvažte následující pokyny týkající se monitorování platformy.

Application Gateway

Application Gateway monitoruje stav prostředků ve svém back-endovém fondu. Pomocí protokolů přístupu ke službě Application Gateway můžete shromažďovat informace, jako je časové razítko, kód odpovědi HTTP a cesta url. Další informace najdete v tématu Výchozí sonda stavu služby Application Gateway, stav back-endu a diagnostické protokoly.

App Service

App Service obsahuje integrované a integrované monitorovací nástroje, které byste měli povolit pro lepší pozorovatelnost. Pokud už vaše webová aplikace obsahuje funkce telemetrie a monitorování (instrumentace v procesu), měla by dál fungovat ve službě App Service.

  • Povolte automatickou instrumentaci. App Service má rozšíření instrumentace, které můžete povolit beze změn kódu. Získáte viditelnost monitorování výkonu aplikací (APM). Další informace najdete v tématu Monitorování výkonu služby Aplikace Azure Service.
  • Povolte distribuované trasování. Automatické instrumentace nabízí způsob, jak monitorovat distribuované cloudové systémy prostřednictvím distribuovaného trasování a profileru výkonu.
  • Pro vlastní telemetrii použijte instrumentaci založenou na kódu. Aplikace Azure lication Insights také podporuje instrumentaci založenou na kódu pro vlastní telemetrii aplikací. Přidejte do kódu sadu Application Insights SDK a použijte rozhraní API Application Insights.
  • Povolte protokoly služby App Service. Platforma App Service podporuje čtyři další protokoly, které byste měli povolit pro podporu řešení potíží. Tyto protokoly jsou aplikační protokoly, protokoly webového serveru, podrobné chybové zprávy a trasování neúspěšných požadavků.
  • Používejte strukturované protokolování. Přidejte do kódu aplikace knihovnu strukturovaného protokolování. Aktualizujte kód tak, aby používal páry klíč-hodnota, a povolte aplikační protokoly ve službě App Service, aby se tyto protokoly ukládaly do pracovního prostoru služby Log Analytics.
  • Zapněte kontrolu stavu služby App Service. Kontrola stavu směruje požadavky mimo instance, které nejsou v pořádku, a nahrazuje instance, které nejsou v pořádku. Aby fungovaly kontroly stavu, musí váš plán služby App Service používat dvě nebo více instancí.
Databáze

Řízení

Webové aplikace využívají Azure Policy vynucením rozhodnutí o architektuře a zabezpečení. Azure Policy může znemožnit nasazení (1) nebo (2) snadné rozpoznání (auditování) posunu konfigurace od upřednostňovaného požadovaného stavu. To vám pomůže zachytit nasazení infrastruktury jako kód (IaC) nebo změny webu Azure Portal, které se odchylují od schválené architektury. Všechny prostředky byste měli umístit do architektury v rámci zásad správného řízení služby Azure Policy. Pokud je to možné, použijte předdefinované zásady nebo iniciativy zásad, které umožňují vynutit základní topologii sítě, funkce služeb, zabezpečení a monitorování, například:

  • App Service by měla zakázat přístup k veřejné síti
  • Služba App Service by měla používat integraci virtuální sítě.
  • Služba App Service by měla pro připojení ke službám PaaS používat Azure Private Link.
  • Služba App Service by měla mít pro nasazení webu FTP a SCM zakázané místní metody ověřování.
  • Služba App Service by měla mít vypnuté vzdálené ladění.
  • Aplikace služby App Service by měly používat nejnovější verzi protokolu TLS.
  • Měla by být povolená služba Microsoft Defender for App Service.
  • Firewall webových aplikací (WAF) by měl být povolený pro službu Application Gateway.

Podívejte se na další předdefinované zásady pro klíčové služby, jako jsou application gateway a síťové komponenty, App Service, Key Vault a monitorování. Pokud předdefinované zásady plně nepokrývají vaše potřeby, můžete vytvořit vlastní zásady nebo použít zásady komunity (například z cílových zón Azure). Pokud jsou k dispozici, upřednostňte předdefinované zásady.

Další kroky