Ez a cikk áttekintést nyújt a biztonságos alkalmazások Azure-alkalmazás service environment használatával 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-alkalmazás Gateway szolgáltatást és az Azure Web Application Firewallot használja. Ez a cikk útmutatást nyújt az Azure DevOpst használó App Service-környezetek 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 bank- és biztosításipar, ahol az ügyfelek az alkalmazásszintű biztonság mellett a platformszintű biztonságot is figyelembe vehetik. Ezeknek a fogalmaknak a bemutatásához egy olyan alkalmazást fogunk használni, amely lehetővé teszi a felhasználók számára, hogy 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 extra biztonságra van szükség.
- Dedikált bérlői bérlői app service-csomagok helyett dedikált bérlői előfizetést biztosít.
- Az Azure DevOps használata belsőleg elosztott terhelésű (ILB) Application Service-környezettel.
Architektúra
Töltse le az architektúra Visio-fájlját.
Adatfolyam
- A HTTP/HTTPS-kérelmek először az Application Gatewayre érnek.
- Opcionálisan (a diagramon nem látható) engedélyezve lehet a Microsoft Entra-hitelesítés a webalkalmazáshoz. Miután a forgalom először elérte az Application Gatewayt, a rendszer kérni fogja a felhasználót, hogy adjon meg hitelesítő adatokat az alkalmazással való hitelesítéshez.
- A felhasználói kérések a környezet belső terheléselosztójában (ILB) haladnak át, ami viszont a forgalmat a Expenses Web Appba irányítja.
- A felhasználó ezután létrehoz egy költségjelentést.
- A költségjelenté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.
- A létrehozott költségjelentés az Azure SQL Database-ben van tárolva.
- A folyamatos üzembe helyezés megkönnyítése érdekében a kód be van jelentkezve az Azure DevOps-példányba.
- A buildelési virtuális gépre telepítve van az Azure DevOps Agent, amely lehetővé teszi, hogy a buildelési virtuális gép lekérje a webalkalmazás bitjeinek az App Service-környezetben való üzembe helyezését (mivel a buildelési virtuális gép egy ugyanazon virtuális hálózaton belüli alhálózaton van üzembe helyezve).
Összetevők
- Az 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 az App Service-környezet é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ény az ILB App Service-környezet kiválasztását hajtotta.
- Ez a számítási feladat az App Service izolált tarifacsomagját használja, így az alkalmazás privát dedikált környezetben fut egy Azure-adatközpontban gyorsabb processzorokkal, SSD-tárterülettel, és megduplázza a memória-mag arányt a Standardhoz képest.
- Azure-alkalmazás Szolgáltatások A Web App és az API App webalkalmazásokat és RESTful API-kat üzemeltet. Ezek az alkalmazások és API-k az Izolált szolgáltatáscsomagban találhatók, amely automatikus skálázást, egyéni tartományokat és egyebeket is kínál, de dedikált szinten.
- Az Azure Application Gateway egy webes forgalom terheléselosztója, amely a 7. rétegben működik, és kezeli a webalkalmazás felé irányuló forgalmat. SSL-kiszervezést kínál, amely eltávolítja a webalkalmazást üzemeltető webkiszolgálók többletterhelését a forgalom ismételt visszafejtéséhez.
- A webalkalmazási tűzfal (WAF) az Application Gateway egyik funkciója. A WAF engedélyezése az Application Gatewayben tovább növeli a biztonságot. A WAF OWASP-szabályokat használ a webalkalmazás védelmére 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.
- Az Azure SQL Database 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 Networking 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. Csatlakozás helyszíni adatközpontokkal az ExpressRoute-on vagy a helyek közötti kapcsolaton keresztül is létrehozható. 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 az 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étre lett hozva egy Azure buildelési virtuális gép , hogy a telepített ügynök le tudja húzni a megfelelő buildet, és üzembe helyezhesse a webalkalmazást a környezetben.
Alternatívák
Az App Service-környezetek normál webalkalmazásokat futtathatnak Windows rendszeren, vagy a példához hasonlóan a linuxos tárolóként futó környezetben üzembe helyezett webalkalmazásokat. Egy App Service-környezet lett kiválasztva 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örnyezete többnyire Windows-alapú, és a számítási feladatok elsősorban .NET-keretrendszer-alapúak, és nem fontolgatja a .NET Core-ba 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 Kiéphetők Windowson vagy Linuxon.
- Az 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.
Considerations
Az ILB App Service-környezet 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 tároló kiszolgáló által létrehozott tanúsítvány-aláírási kérést kellene megkövetelnie. 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.
Az App Service-környezet belső Terheléselosztójából (ILB) nem állíthat ki CSR-t. 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ő eljárás ellenőrzi, hogy a rekord ott van-e, és ha megtalálható, tudja, hogy a DNS-kiszolgáló tulajdonosa, mert a megfelelő rekorddal rendelkezik. Ezen információk alapján olyan tanúsítványt állít ki, amely egy megbízható gyökérre van regisztrálva, amelyet aztán feltölthet az ILB-be. Nem kell semmit tennie a Web Apps egyes tanúsítványtárolóival, 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-környezetben futó szolgáltatások között, működjön az önaláírt vagy belsőleg kiadott SSL-tanúsítvány. Egy másik megoldás, amely azt vizsgálja meg, hogyan használható az ILB App Service Environment belsőleg kiadott SSL-tanúsítvánnyal, és hogyan töltheti be a belső hitelesítésszolgáltatót a megbízható legfelső szintű tárolóba.
Az App Service-környezet 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-környezet által használt tartománynév nem fedheti át egymást. A contoso.com tartománynévvel rendelkező ILB App Service-környezetek esetében 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-környezethez, 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, mivel ez nem ütközik a .contoso.com végződésű egyéni tartománynevekkel.
Egy másik megfontolandó szempont a DNS. Annak érdekében, hogy az App Service-környezetben lévő alkalmazások kommunikálhassanak egymással, például egy webalkalmazással, hogy egy API-val beszéljenek, konfigurálnia kell a DNS-t a környezetet tartalmazó virtuális hálózathoz. Használhatja saját DNS-ét, vagy használhatja az Azure DNS privát zónákat.
Elérhetőség
- A felhőalkalmazás létrehozásakor fontolja meg a rendelkezésre állás tipikus tervezési mintáinak alkalmazását.
- Tekintse át a rendelkezésre állással kapcsolatos szempontokat a megfelelő App Service webalkalmazás-referenciaarchitektúrában.
- A rendelkezésre állással kapcsolatos egyéb szempontokat az Azure Architecture Center rendelkezésre állási ellenőrzőlistájában talál.
Méretezhetőség
- Ismerje meg, hogyan működik a méretezés az App Service-környezetekben.
- Tekintse át a felhőalapú alkalmazások automatikus skálázásának ajánlott eljárásait.
- Felhőalkalmazások létrehozásakor vegye figyelembe a méretezhetőség tipikus tervezési mintáit.
- Tekintse át a méretezhetőség szempontjait a megfelelő App Service webalkalmazás-referenciaarchitektúrában.
- További méretezhetőségi cikkekért tekintse meg az Azure Architecture Centerben elérhető teljesítményhatékonysági ellenőrzőlistát .
Biztonság
- Tekintse át a biztonsági pillér áttekintését.
- Tekintse át a biztonsági szempontokat a megfelelő App Service webalkalmazás-referenciaarchitektúrában.
- Fontolja meg egy biztonságos fejlesztési életciklus-folyamat követését, hogy a fejlesztők biztonságosabb szoftvereket építsenek ki, és megfeleljenek a biztonsági megfelelőségi követelményeknek, miközben csökkentik a fejlesztési költségeket.
- Tekintse át az Azure PCI DSS-megfelelőség tervarchitektúrájának áttekintését.
- Az Azure DDoS Protection alkalmazástervezési ajánlott eljárásokkal kombinálva továbbfejlesztett DDoS-kockázatcsökkentési funkciókat biztosít, hogy nagyobb védelmet nyújtson a DDoS-támadásokkal szemben. Az Azure DDOS Protectiont minden peremhálózaton engedélyeznie kell.
Tartósság
- Fontolja meg a Geo Distributed Scale és az App Service-környezetek használatát a nagyobb rugalmasság és skálázhatóság érdekében.
- Tekintse át a rugalmasságra jellemző tervezési mintákat, és szükség esetén fontolja meg ezeknek a megvalósítását.
- Az App Service-hez ajánlott eljárások az Azure Architecture Centerben találhatók.
- Fontolja meg az aktív georeplikálás használatát az adatszint és a georedundáns tárolás esetében a képek és üzenetsorok esetében.
- A rugalmasságról bővebben az Azure Architecture Center vonatkozó cikkében olvashat.
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 az 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.
Pricing
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égprofilt adtunk meg a várt forgalom alapján:
- Kicsi: Ez a díjszabási példa a néhány ezer felhasználót havonta kiszolgáló minimális éles szintű példányhoz szükséges összetevőket jelöli. 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 alapszintűre van skálázva, amely minimalizálja a költségeket, de továbbra is biztosítja, hogy az SLA-támogatás és a kapacitás elegendő legyen az éles szintű számítási feladatok kezeléséhez.
- 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 egy mérsékelt standard szintű App Service-példányban lesz kezelve. Emellett a kognitív és keresési szolgáltatások mérsékelt szintjei is hozzáadódnak a számológéphez.
- Nagy: Ez a díjszabási példa egy nagy léptékű, havonta több millió felhasználót tartalmazó alkalmazásokat jelöl, amely több 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 helyez üzembe. Az adatok a következő összetevőkből állnak: tárolás, adatbázisok és CDN, mind több terabájtnyi adathoz 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
- Részletes üzembe helyezési oktatóanyag
- Integrate your ILB App Service Environment with the Azure Application Gateway
- A Web Apps integrálása a Azure-alkalmazás-átjáróval
- Földrajzilag elosztott skálázás App Service-környezetekkel