Szerkesztés

Biztonságosan felügyelt webalkalmazások

App Service
Application Gateway
SQL Database
VPN Gateway
Webalkalmazási tűzfal

Ez a cikk áttekintést nyújt a biztonságos alkalmazások Azure App Service környezettel történő üzembe helyezéséről. Az alkalmazás internetről való hozzáférésének korlátozásához a Azure Application Gateway szolgáltatást és az Azure Web Application Firewall használjuk. Ez a cikk útmutatást nyújt a App Service Környezetek azure DevOps használatával történő folyamatos integrációjáról és folyamatos üzembe helyezéséről (CI/CD).

Ezt a forgatókönyvet gyakran alkalmazzák olyan iparágakban, mint a bankolás és a biztosítás, ahol az ügyfelek az alkalmazásszintű biztonság mellett a platformszintű biztonságot is tudatosan használják. Ezeknek a fogalmaknak a bemutatásához egy olyan alkalmazást fogunk használni, amely lehetővé teszi, hogy a felhasználók költségjelentéseket küldjenek.

Lehetséges használati esetek

Fontolja meg ezt a forgatókönyvet a következő használati esetekben:

  • Azure-webalkalmazás létrehozása, ahol további biztonságra van szükség.
  • Dedikált bérlő biztosítása a megosztott bérlői App Service csomagok helyett.
  • Az Azure DevOps használata belsőleg elosztott terhelésű (ILB) Application Service-környezettel.

Architektúra

A biztonságos ILB-App Service Environment üzembe helyezéséhez használható példaforgatókönyv-architektúrát bemutató ábra.

Töltse le az architektúra Visio-fájlját.

Adatfolyam

  1. A HTTP/HTTPS-kérések először a Application Gateway érik el.
  2. Ha nem jelenik meg a diagramon, engedélyezve lehet az Azure Active Directory -hitelesítés (Azure AD) a webalkalmazásban. Miután a forgalom először elérte a Application Gateway, a rendszer kérni fogja a felhasználót, hogy adjon meg hitelesítő adatokat az alkalmazással való hitelesítéshez.
  3. A felhasználói kérések a környezet belső terheléselosztójában (ILB) haladnak át, amely a forgalmat a Költségek webalkalmazásba irányítja.
  4. A felhasználó ezután létrehoz egy költségjelentést.
  5. A költségelszámolás létrehozása során a rendszer meghívja az üzembe helyezett API-alkalmazást a felhasználó felettese nevének és e-mail-címének lekéréséhez.
  6. A létrehozott költségelszámolást a rendszer Azure SQL Database-ben tárolja.
  7. A folyamatos üzembe helyezés megkönnyítése érdekében a rendszer ellenőrzi a kódot az Azure DevOps-példányban.
  8. A buildelési virtuális gépen telepítve van az Azure DevOps-ügynök, amely lehetővé teszi, hogy a build virtuális gép lekérje a webalkalmazás bitjeinek üzembe helyezését a App Service Environment (mivel a virtuális gép összeállítása ugyanazon a virtuális hálózaton belüli alhálózaton van üzembe helyezve).

Összetevők

  • A App Service Environment egy teljesen elkülönített, dedikált környezetet biztosít az alkalmazás nagy léptékű biztonságos futtatásához. Emellett mivel a App Service Environment és a rajta futó számítási feladatok egy virtuális hálózat mögött találhatók, további biztonsági és elkülönítési réteget is biztosít. A nagy léptékű és elkülönítési követelmények az ILB-App Service Environment kiválasztását vezettek.
  • Ez a számítási feladat az elkülönített App Service tarifacsomagot használja, így az alkalmazás privát dedikált környezetben fut egy Azure-adatközpontban gyorsabb processzorokkal, SSD-tárolókkal, és a standardhoz képest megduplázza a memória-mag arányt.
  • Azure-alkalmazás Services Web App és API App webalkalmazásokat és RESTful API-kat üzemeltet. Ezeket az alkalmazásokat és API-kat az Izolált szolgáltatáscsomag üzemelteti, amely automatikus skálázást, egyéni tartományokat és így tovább, de dedikált szintet kínál.
  • Az Azure Application Gateway a 7. rétegben működő webes forgalom terheléselosztója, amely a webalkalmazás felé irányuló forgalmat kezeli. SSL-kiszervezést kínál, amely eltávolítja a többletterhelést a webalkalmazást üzemeltető webkiszolgálókról a forgalom ismételt visszafejtéséhez.
  • Web Application Firewall (WAF) a Application Gateway egyik funkciója. A WAF engedélyezése a Application Gateway tovább növeli a biztonságot. A WAF OWASP-szabályokat használ a webalkalmazás védelméhez olyan támadások ellen, mint a helyek közötti szkriptelés, a munkamenet-eltérítések és az SQL-injektálás.
  • Azure SQL adatbázis azért lett kiválasztva, mert az alkalmazás legtöbb adata relációs adat, néhány adat dokumentumként és blobként.
  • Az Azure-hálózatkezelés különböző hálózati képességeket biztosít az Azure-ban, és a hálózatok más Azure-beli virtuális hálózatokkal is társíthatók. A helyszíni adatközpontokkal az ExpressRoute vagy a helyek közötti kapcsolatok is létesíthetők. Ebben az esetben a szolgáltatásvégpont engedélyezve van a virtuális hálózaton, hogy az adatok csak az Azure-beli virtuális hálózat és a SQL Database példány között folyjanak.
  • Az Azure DevOps segítségével a csapatok együttműködhetnek a futamok során, az Agilis fejlesztést támogató funkciókkal, valamint buildelési és kiadási folyamatokat hozhatnak létre.
  • Létrehoztunk egy Azure build virtuális gépet , hogy a telepített ügynök lekérhesse a megfelelő buildet, és üzembe helyezhesse a webalkalmazást a környezetben.

Alternatív megoldások

Egy App Service Environment normál webalkalmazásokat futtathat Windows rendszeren, vagy az ebben a példában ismertetett módon a környezetben telepített webalkalmazásokat, amelyek mindegyike Linux-tárolóként fut. Kiválasztottunk egy App Service Environment ezeknek az egypéldányos tárolóalapú alkalmazásoknak a üzemeltetéséhez. Léteznek alternatívák – tekintse át az alábbi szempontokat a megoldás tervezésekor.

  • Azure Service Fabric: Ha a környezet többnyire Windows-alapú, és a számítási feladatok elsősorban .NET-keretrendszer-alapúak, és nem fontolgatja a .NET Core-ra való újratervezést, akkor a Service Fabric használatával támogassa és telepítse a Windows Server-tárolókat. A Service Fabric emellett támogatja a C#- vagy Java-programozási API-kat, és natív mikroszolgáltatások fejlesztéséhez a fürtök Windowson vagy Linuxon is kiépülhetnek.
  • Azure Kubernetes Service (AKS) egy nyílt forráskódú projekt és egy vezénylési platform, amely alkalmasabb összetett többkontainer alkalmazások üzemeltetésére, amelyek jellemzően mikroszolgáltatás-alapú architektúrát használnak. Az AKS egy felügyelt Azure-szolgáltatás, amely elvonja a Kubernetes-fürtök kiépítésének és konfigurálásának bonyolultságait. A Kubernetes-platform támogatásához és karbantartásához azonban jelentős ismeretekre van szükség, ezért előfordulhat, hogy néhány egypéldányos tárolóalapú webalkalmazás üzemeltetése nem a legjobb megoldás.

Az adatszint további lehetőségei a következők:

  • Azure Cosmos DB: Ha az adatok többsége nem relációs formátumú, az Azure Cosmos DB jó alternatíva. Ez a szolgáltatás platformot biztosít más adatmodellek, például a MongoDB, a Cassandra, a Graph-adatok vagy az egyszerű táblatárolók futtatásához.

Megfontolandó szempontok

Az ILB-App Service Environment tanúsítványainak kezelésekor bizonyos szempontokat figyelembe kell venni. Olyan tanúsítványt kell létrehoznia, amely egy megbízható gyökerhez van láncolva anélkül, hogy a tanúsítványt végül tároló kiszolgáló által létrehozott tanúsítvány-aláírási kérésre lenne szükség. Az Internet Information Services (IIS) használatával például az első lépés egy CSR létrehozása az IIS-kiszolgálóról, majd elküldése az SSL-tanúsítványkibocsátó szolgáltatónak.

Egy App Service Environment belső Load Balancer (ILB) nem tud CSR-t kibocsátni. A korlátozás kezelésének módja a helyettesítő karakteres eljárás használata.

A helyettesítő karakteres eljárás lehetővé teszi a DNS-név tulajdonjogának igazolását CSR helyett. Ha rendelkezik DNS-névtérrel, speciális DNS TXT rekordot helyezhet el, a helyettesítő karakteres eljárás ellenőrzi, hogy a rekord ott van-e, és ha megtalálta, tudja, hogy a DNS-kiszolgáló a tulajdonosa, mert a megfelelő rekorddal rendelkezik. Ezen információk alapján egy megbízható gyökerre regisztrált tanúsítványt bocsát ki, amelyet aztán feltölthet az ILB-be. Nem kell semmit tennie az egyes tanúsítványtárolókkal a Web Apps, mert megbízható legfelső szintű SSL-tanúsítvánnyal rendelkezik az ILB-ben.

Ha biztonságos hívásokat szeretne kezdeményezni az ILB-App Service Environment futó szolgáltatások között, végezze el az önaláírt vagy belsőleg kiadott SSL-tanúsítvány használatát. Egy másik megoldás, amellyel az ILB-App Service Environment a belsőleg kibocsátott SSL-tanúsítvánnyal és a belső hitelesítésszolgáltató megbízható legfelső szintű tárolóba való betöltésének módjával kapcsolatban érdemes megfontolni.

A App Service Environment kiépítése során vegye figyelembe a következő korlátozásokat a környezet tartománynevének kiválasztásakor. A tartománynevek nem lehetnek:

  • net
  • azurewebsites.net
  • p.azurewebsites.net
  • nameofthease.p.azurewebsites.net

Ezenkívül az alkalmazásokhoz használt egyéni tartománynév és az ILB App Service Environment által használt tartománynév nem fedheti át egymást. A contoso.com tartománynévvel rendelkező ILB-App Service Environment nem használhat egyéni tartományneveket az alkalmazásokhoz, például:

  • www.contoso.com
  • abcd.def.contoso.com
  • abcd.contoso.com

Válasszon egy tartományt az ILB-App Service Environment, amely nem ütközik az egyéni tartománynevekkel. Ebben a példában a környezet tartományához hasonló contoso-internal.com használhat, mert ez nem ütközik a .contoso.com végződésű egyéni tartománynevekkel.

Egy másik megfontolandó szempont a DNS. Ahhoz, hogy a App Service Environment belüli alkalmazások kommunikálhassanak egymással, például egy webalkalmazásnak egy API-val való kommunikációhoz, konfigurálnia kell a DNS-t a környezetet tároló virtuális hálózathoz. Használhatja saját DNS-ét, vagy használhatja az Azure DNS privát zónákat.

Rendelkezésre állás

Méretezhetőség

Biztonság

Rugalmasság

A forgatókönyv üzembe helyezése

A forgatókönyv üzembe helyezéséhez kövesse ezt a lépésenkénti oktatóanyagot , amely bemutatja, hogyan helyezheti üzembe manuálisan az egyes összetevőket. Az oktatóanyag követésekor válassza App Service Environment v3-at a v2 helyett. Ez az oktatóanyag egy .NET-mintaalkalmazást is biztosít, amely egy egyszerű Contoso költségjelentési alkalmazást futtat.

Díjszabás

A forgatókönyv futtatásának költségeinek megismerése. Az összes szolgáltatás előre konfigurálva van a költségkalkulátorban. Annak megtekintéséhez, hogy az adott használati eset díjszabása hogyan változna, módosítsa a megfelelő változókat a várt forgalomnak megfelelően.

Három költségprofil-mintaprofilt adtunk meg a várható forgalom mennyisége alapján:

  • Kicsi: Ez a díjszabási példa a havi néhány ezer felhasználót kiszolgáló minimális éles szintű példányhoz szükséges összetevőket mutatja be. Az alkalmazás egy szabványos webalkalmazás egyetlen példányát használja, amely elegendő lesz az automatikus skálázás engedélyezéséhez. A többi összetevő egy alapszintre van skálázva, amely minimalizálja a költségeket, de továbbra is biztosítja az SLA támogatását és az éles szintű számítási feladatok kezeléséhez szükséges kapacitást.
  • Közepes: Ez a díjszabási példa a közepes méretű üzembe helyezéshez szükséges összetevőket jelöli. Itt körülbelül 100 000 felhasználót becsülünk meg egy hónap alatt. A várt forgalom egyetlen app service-példányban, mérsékelt standard szinttel kezelhető. Emellett a kognitív és keresési szolgáltatások mérsékelt szintjei is bekerülnek a kalkulátorba.
  • Nagyméretű: Ez a díjszabási példa egy nagy léptékű, havonta több millió felhasználóra szánt alkalmazást jelöl, amely terabájtnyi adatot helyez át. Ezen a használati szinten nagy teljesítményű, prémium szintű webalkalmazásokra van szükség, amelyeket a Traffic Manager több régióban is üzembe helyez. Az adatok a következő összetevőkből állnak: tárolás, adatbázisok és CDN, ezek mindegyike terabájtnyi adathoz van konfigurálva.

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerző:

  • Faisal Mustafa | Vezető ügyfélmérnök

Következő lépések