Az Azure Virtual Machines alaparchitektúrája egy Azure-beli célzónában

A jelen cikkben szereplő architektúra kibővül a virtuális gép (VM) alaparchitektúráján , hogy megfeleljen a változásoknak és elvárásoknak, amikor üzembe helyezi azt egy Azure-beli célzónában.

A jelen cikkben szereplő példában egy szervezet egy virtuálisgép-alapú számítási feladatot szeretne használni a platformcsapat által központilag kezelt összevont erőforrások használatára. Ezek az erőforrások közé tartoznak a hálózatkezelési erőforrások a helyek közötti kapcsolathoz, az identitáshozzáférés-kezeléshez és a szabályzatokhoz. Ez a példa feltételezi, hogy a szervezet azure-beli célzónákat vezet be, hogy egységes szabályozást és költséghatékonyságot kényszerítsen ki több számítási feladatra.

Számítási feladat tulajdonosaként kioszthatja a megosztott erőforrások felügyeletét a központi csapatoknak, így a számítási feladatok fejlesztésére összpontosíthat. Ez a cikk a számítási feladatok csapatának perspektíváját mutatja be. Javaslatok, amelyek a platformcsapathoz tartoznak, meg vannak adva.

Cikkelrendezés

Architektúra	Tervezési döntés	Az Azure Well-Architected Framework megközelítése
▪ Architektúradiagram ▪ Számítási feladatok erőforrásai ▪ Összevont erőforrások	▪ Előfizetés beállítása ▪ Hálózatkezelési követelmények ▪ A hálózattervezés változásai az alaptervtől ▪ Megfigyelő ▪ Javítás megfelelősége ▪ Szervezeti irányítás ▪ Változáskezelés	▪ Megbízhatóság ▪ Biztonsági ▪ Költségoptimalizálás

Architektúra

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

Összetevők

Minden Azure-beli célzóna-architektúra külön tulajdonosi viszonyban van a platformcsapat és a számítási feladatokkal foglalkozó csapat között. Az alkalmazástervezőknek és a DevOps-csapatoknak tisztában kell lenni ezzel a felosztással, hogy megértsék, mi van a közvetlen befolyásuk vagy irányításuk alatt, és mi nem.

Számítási feladatok csapat tulajdonában lévő erőforrások

A következő erőforrások többnyire változatlanok maradnak az alaparchitektúra alapján.

• Az Azure Virtual Machines az alkalmazásplatform. A számítási erőforrások a rendelkezésre állási zónák között vannak elosztva.

• Az Azure Load Balancer az előtérbeli virtuális gépek és a háttérbeli virtuális gépek közötti forgalom privát terheléselosztására szolgál. A terheléselosztó elosztja a forgalmat a virtuális gépek között a zónák között.

• Azure-alkalmazás Átjáró fordított proxyként szolgál a felhasználói kérések előtérbeli virtuális gépekre való átirányításához. A kiválasztott termékváltozat az Azure Web Application Firewall üzemeltetésére is használható, hogy megvédje az előtérbeli virtuális gépeket a potenciálisan rosszindulatú forgalomtól.

• Az Azure Key Vault az alkalmazás titkos kulcsainak és tanúsítványainak tárolására szolgál.

• Az Azure Monitor, a Log Analytics és az Application Elemzések a megfigyelhetőségi adatok gyűjtésére, tárolására és megjelenítésére szolgálnak.

• Az Azure Policy a számítási feladatra vonatkozó szabályzatok alkalmazására szolgál.

A számítási feladatokért felelős csapat a következő erőforrásokat és feladatokat tartja fenn és látja el.

• Küllős virtuális hálózati alhálózatok és az ezeken az alhálózatokon elhelyezett hálózati biztonsági csoportok (NSG-k) a szegmentálás fenntartása és a forgalom szabályozása érdekében.

• Privát végpontok a szolgáltatásként nyújtott platform (PaaS) megoldásokhoz és az ezekhez a végpontokhoz szükséges privát DNS-zónákhoz való biztonságos kapcsolódáshoz.

• Az Azure Managed Disks a naplófájlokat a háttérkiszolgálókon tárolja, és az adatok akkor is megmaradnak, amikor a virtuális gépek újraindulnak. Az előtér-kiszolgálókhoz olyan lemezek vannak csatlakoztatva, amelyekkel üzembe helyezheti az állapot nélküli alkalmazást.

Platformcsapat tulajdonában lévő erőforrások

A platformcsapat birtokolja és karbantartja ezeket a központosított erőforrásokat. Ez az architektúra feltételezi, hogy ezek az erőforrások előre ki vannak építve, és függőségeknek tekintik őket.

• A központi hálózaton található Azure Firewall a kimenő forgalom vizsgálatára és korlátozására szolgál. Ez az összetevő az alaparchitektúra standard terheléselosztóját váltja fel, amely nem korlátozza az internet felé irányuló kimenő forgalmat.

• Az Azure Bastion a központi hálózaton biztonságos üzemeltetési hozzáférést biztosít a számítási feladatokat futtató virtuális gépekhez. Az alaparchitektúrában a számítási feladatokért felelős csapaté ez az összetevő.

• A küllős virtuális hálózat az, ahol a számítási feladat üzembe van helyezve.

• A felhasználó által definiált útvonalak (UDR-ek) a központi hálózathoz való bújtatás kényszerítésére szolgálnak.

• Az Azure Policy-alapú szabályozási korlátozások és DeployIfNotExists a (DINE-) szabályzatok a számítási feladatok előfizetésének részét képezik.

Előfizetés beállítása

A kezdőzóna-környezetben a számítási feladatokkal foglalkozó csapatnak tájékoztatnia kell a platformcsapatot az adott követelményekről.

A számítási feladatokért felelős csapatnak részletes információkat kell tartalmaznia a számítási feladathoz szükséges hálózati területről, hogy a platformcsapat lefoglalhassa a szükséges erőforrásokat. A csapat határozza meg a követelményeket, a platformcsapat pedig meghatározza a virtuális hálózaton belül hozzárendelni kívánt IP-címeket, valamint azt a felügyeleti csoportot, amelyhez az előfizetés hozzá van rendelve.

A platformcsapat hozzárendel egy megfelelő felügyeleti csoportot a számítási feladat üzleti kritikussági és műszaki követelményei alapján, például ha egy számítási feladat elérhető az interneten. A szervezet határozza meg ezeknek a felügyeleti csoportoknak a konfigurációját, és a platformcsapat implementálja őket.

Az alaparchitektúra alkalmazásforgatókönyveinek felügyeleti csoportjai például a következők:

• Magánalkalmazások, például belső üzletági alkalmazások vagy kereskedelmi célú, nem polcon lévő (COTS-) megoldások, amelyek gyakran az Azure-beli célzónák Corp felügyeleti csoportjában találhatók.

• Nyilvános alkalmazások, mint az internetes alkalmazások esetében, amelyek gyakran a Corp vagy az Online felügyeleti csoport alá tartoznak.

A platformcsapat felelős egy előfizetés vagy előfizetéscsoport beállításáért is a számítási feladatok üzembe helyezéséhez.

Az alábbi szakaszok útmutatást nyújtanak az előfizetés kezdeti beállításához. A platformcsapat azonban általában módosítja a központosított szolgáltatásokat az elmulasztott vagy módosított követelmények kezelése érdekében. A platformmódosítások szélesebb körű hatást gyakorolnak az összes számítási feladatcsoportra.

Ezért a platformcsapatnak biztosítania kell, hogy minden virtuálisgép-számítási feladat felkészüljön a változásokra, és tisztában kell lenniük a virtuálisgép-alapú megoldás életciklusával és a tesztelési ciklusával. További információ: Változások kezelése az idő függvényében.

Számítási feladatokra vonatkozó követelmények és teljesítések

A számítási feladatokért felelős csapat és a platformcsapat két fő feladattal rendelkezik: a felügyeleti csoportok hozzárendelésével és a hálózatkezelés beállításával. Ehhez az architektúrához vegye figyelembe a következő hálózati követelményeket, amelyeket a platformcsapatnak kell kommunikálnia. Ezeket a pontokat példákként használva megismerheti a két csapat közötti beszélgetést és egyeztetést egy hasonló architektúra megvalósításakor.

• Küllős virtuális hálózatok száma: Ebben az architektúrában csak egy dedikált küllő szükséges. Az üzembe helyezett erőforrásoknak nem kell több hálózatra kiterjednie, és egyetlen virtuális hálózaton belül vannak egymás mellett.

• A küllős hálózat mérete: Vegye figyelembe az üzemeltetési követelményeket és a számítási feladatok várható növekedését. Ha például kék/zöld vagy kanári frissítéseket szeretne implementálni, a maximális méretnek figyelembe kell vennie azt a helyet, amelyet a párhuzamos üzembe helyezések igényelnek.

  A jövőbeni módosításokhoz több IP-címterületre lehet szükség, ami az aktuális foglalással való eltéréshez vezethet. Ezeknek a tereknek az integrációja további összetettséghez vezethet. Legyen proaktív, és kérjen elegendő hálózati erőforrást előre, hogy a lefoglalt terület képes legyen a jövőbeli bővítésre.

• Az üzembehelyezési régió: Fontos megadni azokat a régiókat, ahol a számítási feladat üzembe lesz helyezve. A platformcsapat ezen információk segítségével biztosíthatja, hogy a küllős és központi virtuális hálózatok ugyanabban a régióban legyenek kiépítve. A különböző régiók hálózatai késési problémákhoz vezethetnek a regionális határokon áthaladó forgalom miatt, és további sávszélesség-költségekkel is járhatnak.

• A számítási feladatok jellemzői és a tervezési lehetőségek: A tervezési lehetőségek, összetevők és jellemzők kommunikálása a platformcsapattal. Ha például arra számít, hogy a számítási feladat nagy számú egyidejű internetkapcsolatot hoz létre (csevegés), a platformcsapatnak biztosítania kell, hogy elegendő port legyen elérhető a kimerültség megelőzéséhez. IP-címeket adhatnak a központosított tűzfalhoz a forgalom támogatásához, vagy beállíthatnak egy hálózati címfordítási (NAT) átjárót a forgalom másik útvonalon való átirányításához.

  Ezzel szemben, ha azt várja, hogy a számítási feladat minimális hálózati forgalmat (háttérzajt) generáljon, a platformcsapatnak hatékonyan kell használnia az erőforrásokat a szervezetben.

  A platformcsapatnak világosan meg kell értenie a függőségeket. Előfordulhat például, hogy a számítási feladatnak hozzá kell férnie egy másik csapat tulajdonában lévő adatbázishoz, vagy a számítási feladat helyszíni forgalommal rendelkezhet. A számítási feladat rendelkezik az Azure-on kívüli függőségekkel? Ezek az információk fontos, hogy a platform csapata tudja.

• A tűzfal konfigurációja: A platform csapatának tisztában kell lennie a küllős hálózatot elhagyó és a központi hálózatba bújtatott forgalommal. A központ tűzfala nem tudja blokkolni ezt a forgalmat.

  Ha például a számítási feladatnak hozzá kell férnie a Windows-frissítésekhez a javítások megtartásához, a tűzfalnak nem szabad letiltania ezeket a frissítéseket. Hasonlóképpen, ha vannak monitorozási ügynökök, amelyek bizonyos végpontokhoz férnek hozzá, a tűzfalnak nem szabad blokkolnia ezt a forgalmat, mert az megzavarhatja a számítási feladat figyelési adatait. Előfordulhat, hogy az alkalmazás külső végpontokhoz való hozzáférést igényel. Ettől függetlenül használjon központosított tűzfalat a várt és a jogosulatlan forgalom megkülönböztetéséhez.

• Operátori hozzáférés: Ha vannak Olyan Microsoft Entra-azonosítójú biztonsági csoportok, amelyeket az operátorok a virtuális gépek Azure Bastionon keresztüli elérésére használnak, tájékoztassa a platformcsapatot. Az Azure Bastion általában egy központi erőforrás. Elengedhetetlen annak biztosítása, hogy a biztonsági csoportok és a virtuális gépek támogassák a biztonságos protokollt.

  Emellett tájékoztassa a platformcsapatot a virtuális gépeket tartalmazó IP-tartományokról. Ezek az információk szükségesek az Azure Bastion körüli NSG-k központi hálózatban való konfigurálásához.

• Nyilvános IP-címek: Tájékoztassa a platform csapatát a bejövő forgalom profiljáról, beleértve a várható nyilvános IP-címeket is. Ebben az architektúrában csak az internetes forgalom célozza meg a nyilvános IP-címet az Application Gatewayen. A platformcsapatnak tájékoztatnia kell a számítási feladatokkal foglalkozó csapatot, ha ezek az IP-címek Azure DDoS Protection-csomagban vannak, vagy ha a számítási feladatokkal foglalkozó csapat feladata.

  Ebben az architektúrában egy másik nyilvános IP-cím áll rendelkezésre az Azure Bastionon keresztüli üzemeltetési hozzáféréshez. A platformcsapat birtokolja ezt a nyilvános IP-címet, és regisztrálva van egy szolgáltatásban, például a DDoS Protectionben, amelyet a platformcsapat is kezel.

Virtuálisgép-tervezési lehetőségek

A virtuálisgép-termékváltozat és a lemezkijelölések ugyanazok maradnak, mint az alaparchitektúra.

Egy szervezet megfelelőségi követelményeket írhat elő a számítási feladatokat kezelő csapat számára, amely meghatározott virtuálisgép-rendszerképek használatát rendeli el. Az ilyen követelményeknek megfelelően a platform csapata szabványosított rendszerképeket kezelhet, amelyeket gyakran aranylemezképnek neveznek, amelyeket a szervezet egészében használnak.

A platformcsapat egy felügyelt ajánlatot, például az Azure Compute Galleryt vagy egy privát adattárat használhat jóváhagyott operációsrendszer-rendszerképek vagy számítási feladatok összetevőinek tárolására. Amikor operációsrendszer-rendszerképet választ a virtuális gépekhez, forduljon a platform csapatához a képforrásokról, a frissítés gyakoriságáról és a használati elvárásokról. Győződjön meg arról is, hogy a rendszerképek megfelelnek a számítási feladat által támasztott szükséges üzleti követelményeknek.

Hálózat

Az alaparchitektúra a számítási feladatot egyetlen virtuális hálózaton helyezi üzembe. A számítási feladatokat kezelő csapat felügyeli a virtuális hálózatot.

Ebben az architektúrában a platformcsapat határozza meg a hálózati topológiát. A küllős topológiát ebben az architektúrában feltételezzük.

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

• Központi virtuális hálózat: A regionális központok olyan központosított szolgáltatásokat tartalmaznak, amelyek ugyanazon a régióban kommunikálnak a számítási feladatok erőforrásaival. További információkért lásd a platform csapat tulajdonában lévő erőforrásokat. Javasoljuk, hogy helyezze a központot a kapcsolati előfizetésbe.

• Küllős virtuális hálózat: Ebben az architektúrában az alaparchitektúra egyetlen virtuális hálózata a küllős hálózat. A központosított szolgáltatásokat tartalmazó központosított hálózathoz van társítva. A platform csapata birtokolja és kezeli ezt a küllős hálózatot. Ez a hálózat tartalmazza a számítási feladatok erőforrásait. A számítási feladatokért felelős csapat birtokolja a hálózat erőforrásait, beleértve az alhálózatait is.

Győződjön meg arról, hogy közli a számítási feladatokkal kapcsolatos követelményeket a platformcsapattal, és rendszeresen áttekinti őket.

Virtuális hálózati alhálózatok

A küllős virtuális hálózatban a számítási feladatok csapata létrehozza és lefoglalja az alhálózatokat. Az alhálózatokon belüli és kimenő forgalom korlátozására szolgáló vezérlők elhelyezése segít szegmentálást biztosítani. Ez az architektúra ugyanazt az alhálózati topológiát használja, mint az alaparchitektúra, amely dedikált alhálózatokkal rendelkezik az Application Gatewayhez, az előtérbeli virtuális gépekhez, a terheléselosztóhoz, a háttérbeli virtuális gépekhez és a privát végpontokhoz.

Ha a számítási feladatot egy Azure-beli célzónában helyezi üzembe, akkor is hálózati vezérlőket kell implementálnia. A szervezetek korlátozásokat írhatnak elő az adatszivárgás elleni védelem és a központi biztonsági üzemeltetési központ (SOC) és az informatikai hálózati csapat láthatóságának biztosítása érdekében.

Ezzel a megközelítéssel a platformcsapat központosított szolgáltatások használatával optimalizálhatja az általános szervezeti kiadásokat ahelyett, hogy redundáns biztonsági vezérlőket helyez üzembe a szervezet minden számítási feladatához. Ebben az architektúrában az Azure Firewall egy központi szolgáltatás példája. Nem költséghatékony vagy praktikus, ha minden számítási feladatért felelős csapat felügyeli a saját tűzfalpéldányát. A tűzfalkezelés központosított megközelítését javasoljuk.

Bejövő forgalom

A bejövő forgalom ugyanaz marad, mint az alaparchitektúra.

A számítási feladat tulajdonosa felelős minden olyan erőforrásért, amely a nyilvános internetes bejövő forgalomhoz kapcsolódik a számítási feladatba. Ebben az architektúrában például az Application Gateway és a nyilvános IP-címe a küllős hálózatba kerül, nem pedig a központi hálózatba. Egyes szervezetek központosított demilitarizált (DMZ) implementációval helyezhetik el a bejövő forgalommal rendelkező erőforrásokat egy kapcsolati előfizetésben. Az adott topológiával való integráció a jelen cikk hatókörén kívül esik.

Kimenő forgalom

Az alaparchitektúrában a számítási feladatok virtuálisgép-méretezési csoportjai az Azure Load Balanceren keresztül férnek hozzá a nyilvános internethez, de a forgalom nincs korlátozva.

Ez a kialakítás ebben az architektúrában más. A küllős virtuális hálózatot elhagyó összes forgalmat a rendszer egy kimenő tűzfalon keresztül irányítja át a társhálózaton. A küllős hálózat összes lehetséges alhálózatához csatlakozik egy útvonal, amely a helyi virtuális hálózatban nem található IP-címek összes forgalmát (0.0.0.0/0) a központ Azure Firewalljára irányítja.

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

A Key Vault-hozzáférés privát végpontja felé irányuló számítási feladatok közötti kommunikáció ugyanaz marad, mint az alaparchitektúra. Ez az elérési út hiányzik az előző diagramból a rövidítéshez.

A számítási feladatok csapatának azonosítania, dokumentálnia és kommunikálnia kell az infrastruktúra és a számítási feladatok műveleteihez szükséges kimenő forgalomfolyamatokat. A platformcsapat engedélyezi a szükséges forgalmat, és minden nem kommunikált kimenő forgalom valószínűleg megtagadva.

A kimenő forgalom szabályozása több, mint a várt forgalom engedélyezése. Arról is szól, hogy csak a várt forgalom legyen engedélyezve. A nem kommunikált kimenő forgalom valószínűleg alapértelmezés szerint megtagadva, de a számítási feladatnak az a legjobb biztonsági érdeke, hogy a forgalom megfelelően legyen irányítva.

Tájékoztassa a platformcsapatot az egyedi kimenő forgalomra vonatkozó követelményekről. Ha például a számítási feladat számos egyidejű kapcsolatot létesít külső hálózati végpontokkal, tájékoztassa a platformcsapatot. Ezután a platformcsapat kiépíthet egy megfelelő Azure NAT Gateway-implementációt, vagy további nyilvános IP-címeket adhat hozzá a regionális tűzfalhoz a kockázatcsökkentés érdekében.

Előfordulhat, hogy a szervezet olyan követelményekkel rendelkezik, amelyek gátolják az architektúraminták használatát, amelyek számítási feladatokkal rendelkező nyilvános IP-címeket használnak a kimenő forgalomhoz. Ebben az esetben az Azure Policy használatával megtagadhatja a nyilvános IP-címeket a virtuálisgép-hálózati adaptereken (NIC-eken) és bármely más nyilvános IP-címen, a jól ismert bejövő pontokon kívül.

Privát DNS-zónák

A privát végpontokat használó architektúráknak privát DNS-zónákra van szükségük a DNS-szolgáltatóval való együttműködéshez. A számítási feladatokkal foglalkozó csapatnak tisztában kell lennie a privát DNS-zónák követelményeivel és kezelésével a platformcsapat által biztosított előfizetésben. saját DNS zónákat általában nagy méretekben kezelik DINE-szabályzatokkal, ami lehetővé teszi az Azure Firewall számára, hogy megbízható DNS-proxyként működjön, és támogassa a teljes tartománynév (FQDN) hálózati szabályait.

Ebben az architektúrában a platformcsapat biztosítja a privát kapcsolatvégpontok megbízható privát DNS-feloldását. Együttműködhet a platformcsapatával az elvárásaik megértéséhez.

Csatlakozás tivitástesztelés

A virtuálisgép-alapú architektúrákhoz számos olyan teszteszköz van, amely segít meghatározni a hálózati látási, útválasztási és DNS-problémákat. Használhat hagyományos hibaelhárítási eszközöket, például netstat, nslookupvagy tcping. Emellett megvizsgálhatja a hálózati adapter dinamikus gazdakonfigurációs protokollját (DHCP) és DNS-beállításait is. Ha vannak hálózati adapterek, további hibaelhárítási képességekkel rendelkezik, amelyek lehetővé teszik a kapcsolati ellenőrzések végrehajtását az Azure Network Watcher használatával.

Operátori hozzáférés

Az alaparchitektúrához hasonlóan az Azure Bastionon keresztüli üzemeltetési hozzáférés is támogatott ebben az architektúrában.

Az alaparchitektúra azonban a számítási feladat részeként telepíti az Azure Bastiont. Az Azure-beli célzónákat alkalmazó tipikus szervezeteknél központi erőforrásként helyezik üzembe az Azure Bastiont minden régióban. A platformcsapat birtokolja és karbantartja az Azure Bastiont, és a szervezet összes számítási feladatát megosztja. Annak bemutatásához, hogy a használati eset ebben az architektúrában az Azure Bastion a kapcsolati előfizetés központi hálózatában található.

Operátori identitás

Ez az architektúra ugyanazt a hitelesítési bővítményt használja, mint az alaparchitektúra.

Mindig a minimális jogosultság elvével és a feladatokhoz való részletes hozzáférés elvével kezdje a hosszú távú hozzáférés helyett. A kezdőzóna környezetében használja ki a platformcsapat által kezelt igény szerinti (JIT) támogatást.

Javítások megfelelősége és operációsrendszer-frissítések

Az alaparchitektúra a javítások és frissítések autonóm megközelítését írja le. Ha a számítási feladat integrálva van a célzónával, ez a megközelítés megváltozhat. Előfordulhat, hogy a platform csapata diktálja a javítási műveleteket, hogy minden számítási feladat megfeleljen a szervezeti követelményeknek.

Győződjön meg arról, hogy a javítási folyamat tartalmazza az architektúrához hozzáadott összes összetevőt. Ha például úgy dönt, hogy buildügynök virtuális gépeket ad hozzá az alkalmazások üzembe helyezésének, méretezésének és felügyeletének automatizálásához, ezeknek a virtuális gépeknek meg kell felelniük a platformkövetelményeknek.

Figyelés

Az Azure célzónaplatform megosztott megfigyelhetőségi erőforrásokat biztosít a felügyeleti előfizetés részeként. Javasoljuk azonban, hogy saját monitorozási erőforrásokat építsen ki a számítási feladat tulajdonjogi feladatainak megkönnyítése érdekében. Ez a megközelítés összhangban van az alaparchitektúrával.

A számítási feladatokért felelős csapat kiépíti a figyelési erőforrásokat, amelyek a következők:

• Az alkalmazás Elemzések alkalmazásteljesítmény-monitorozási (APM) szolgáltatásként a számítási feladatokat végző csapat számára.

• A Log Analytics-munkaterület egységes fogadóként szolgál a számítási feladat által birtokolt Azure-erőforrásokból és az alkalmazáskódból összegyűjtött összes naplóhoz és metrikához.

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

Az alapkonfigurációhoz hasonlóan az összes erőforrás úgy van konfigurálva, hogy Azure Diagnostics-naplókat küldjön a Log Analytics-munkaterületre, amelyet a számítási feladatok csapata az infrastruktúra részeként az erőforrások kódjának (IaC) üzembe helyezésének részeként helyez üzembe. Előfordulhat, hogy naplókat is el kell küldenie egy központi Log Analytics-munkaterületre. Az Azure-beli célzónákban ez a munkaterület a felügyeleti előfizetésben található.

A platformcsapat olyan DINE-szabályzatokkal is rendelkezhet, amelyekkel konfigurálhatják a Diagnosticst, hogy naplókat küldjenek a központosított felügyeleti előfizetéseiknek. Fontos, hogy az implementáció ne korlátozza a további naplófolyamatokat.

Több fogadó adatainak korrelálása

A számítási feladat naplói és metrikái és infrastruktúra-összetevői a számítási feladat Log Analytics-munkaterületén vannak tárolva. A központi szolgáltatások, például az Azure Firewall, a Microsoft Entra ID és az Azure Bastion által létrehozott naplók és metrikák azonban egy központi Log Analytics-munkaterületen vannak tárolva. Az adatok több fogadóból való korrelációja összetett feladat lehet.

A korrelált adatokat gyakran használják incidenskezeléskor. Ha probléma merül fel több fogadó adatainak korrelációjával kapcsolatban, győződjön meg arról, hogy az architektúra triage runbookja foglalkozik vele, és tartalmazza a szervezeti kapcsolattartási pontokat, ha a probléma túlnyúlik a számítási feladatok erőforrásain. A számítási feladatok rendszergazdáinak segítségre lehet szükségük a platformgazdáktól a vállalati hálózatkezelés, a biztonság vagy más platformszolgáltatások naplóbejegyzéseinek korrelálásához.

Azure Policy

A platformcsapat valószínűleg olyan szabályzatokat alkalmaz, amelyek hatással vannak a számítási feladatok üzembe helyezésére. Gyakran alkalmaznak DINE-szabályzatokat az alkalmazás kezdőzónájának előfizetésében történő automatizált üzembe helyezés kezelésére. A DINE-szabályzatok módosíthatják a számítási feladatok erőforrásait, vagy erőforrásokat adhatnak hozzá az üzemelő példányhoz, ami eltérést eredményezhet a számítási feladatsablonon keresztül deklaratív módon üzembe helyezett erőforrások és a feldolgozási kérelmek által ténylegesen használt erőforrások között. Egy tipikus megoldás, ha imperatív megközelítéssel oldja meg ezeket a módosításokat, amelyek nem ideálisak.

Az eltérés elkerülése érdekében előzetesen építse be és tesztelje a platform által kezdeményezett módosításokat az IaC-sablonokba. Ha a platformcsapat olyan Azure-szabályzatokat használ, amelyek ütköznek az alkalmazás követelményeivel, egyeztethet egy megoldást a platformcsapattal.

Változások kezelése az idő függvényében

A platform által nyújtott szolgáltatások és műveletek az architektúra külső függőségeinek minősülnek. A platformcsapat továbbra is alkalmazza a módosításokat, a felhasználókat és alkalmazza a költségvezérlőket. Előfordulhat, hogy a szervezetet kiszolgáló platformcsapat nem rangsorolja az egyes számítási feladatokat. A függőségek módosítása, függetlenül attól, hogy azok aranylemezkép-módosítások, tűzfalmódosítások, automatikus javítások vagy szabálymódosítások, több számítási feladatot is érinthetnek.

Ezért a számítási feladatokat és platformokat kezelő csapatoknak hatékonyan és időben kell kommunikálniuk az összes külső függőség kezelése érdekében. Fontos a módosítások tesztelése, hogy ne legyenek negatív hatással a számítási feladatokra.

A számítási feladatot érintő platformmódosítások

Ebben az architektúrában a platformcsapat a következő erőforrásokat kezeli. Ezeknek az erőforrásoknak a módosítása hatással lehet a számítási feladat megbízhatóságára, biztonságára, műveleteire és teljesítménycéljaira. Fontos, hogy értékelje ezeket a módosításokat, mielőtt a platform csapata életbe lépteti őket, hogy megállapítsa, hogyan befolyásolják a számítási feladatokat.

• Azure-szabályzatok: Az Azure-szabályzatok módosítása hatással lehet a számítási feladatok erőforrásaira és függőségeikre. Előfordulhat például, hogy közvetlen szabályzatmódosítások vagy a kezdőzóna áthelyezése egy új felügyeleticsoport-hierarchiába. Előfordulhat, hogy ezek a módosítások nem lesznek észrevétlenek, amíg nem lesz új üzembe helyezés, ezért fontos, hogy alaposan teszteljük őket.

• Tűzfalszabályok: A tűzfalszabályok módosítása hatással lehet a számítási feladat virtuális hálózatára vagy az összes forgalomra széles körben alkalmazandó szabályokra. Ezek a módosítások blokkolhatják a forgalmat, és akár csendes folyamathibákat is okozhatnak, például az operációsrendszer-javítások sikertelen alkalmazását. Ezek a lehetséges problémák a kimenő Azure-tűzfalra és az Azure Virtual Network Manager által alkalmazott NSG-szabályokra is érvényesek.

• Megosztott erőforrások: A termékváltozat vagy a megosztott erőforrások funkcióinak módosítása hatással lehet a számítási feladatra.

• Útválasztás a központi hálózaton: A hubon az útválasztás tranzitív jellegének változásai hatással lehetnek a számítási feladatok működésére, ha egy számítási feladat más virtuális hálózatokhoz való útválasztástól függ.

• Azure Bastion-gazdagép: Az Azure Bastion-gazdagép rendelkezésre állásának vagy konfigurációjának módosítása hatással lehet a számítási feladatok műveleteire. Győződjön meg arról, hogy a jump box hozzáférési mintájának változásai hatékony rutinnal, alkalmi és vészhelyzeti hozzáféréssel rendelkeznek.

• Tulajdonosváltozások: A tulajdonosi és kapcsolattartási pontok változásainak közlése a számítási feladatért felelős csapattal, mert ezek hatással lehetnek a számítási feladat felügyeleti és támogatási kérelmeire.

A platformot érintő számítási feladatok változásai

Az alábbi példák a számítási feladatok változásai ebben az architektúrában, amelyeket kommunikálnia kell a platformcsapattal. Fontos, hogy a platformcsapat a hatálybalépés előtt ellenőrizze a platformszolgáltatás megbízhatósági, biztonsági, üzemeltetési és teljesítménycéljait az új számítási feladatok csapatának változásaival szemben.

• Hálózati kimenő forgalom: Monitorozza a hálózati kimenő forgalom jelentős növekedését, hogy a számítási feladat ne váljon zajos szomszédjává a hálózati eszközökön. Ez a probléma hatással lehet más számítási feladatok teljesítmény- vagy megbízhatósági céljaira.

• Nyilvános hozzáférés: A számítási feladatok összetevőihez való nyilvános hozzáférés változásai további tesztelést igényelhetnek. Előfordulhat, hogy a platformcsapat áthelyezi a számítási feladatot egy másik felügyeleti csoportba.

• Üzleti kritikussági értékelés: Ha módosulnak a számítási feladatok szolgáltatásiszint-szerződései (SLA-k), szükség lehet egy új együttműködési megközelítésre a platform és a számítási feladatokat végző csapatok között.

• Tulajdonosváltozások: A tulajdonosi és kapcsolattartási pontok változásainak közlése a platform csapatával.

Számítási feladatokra vonatkozó üzleti követelmények változásai

A számítási feladatok szolgáltatási szintű célkitűzéseinek (SLO-k) fenntartása érdekében előfordulhat, hogy a platformcsapatnak részt kell vennie a számítási feladatok architektúrájának változásaiban. Ezekhez a módosításokhoz szükség lehet a platform csapatának változáskezelésére, vagy annak ellenőrzésére, hogy a meglévő szabályozás támogatja-e a módosított követelményeket.

Közölje például a korábban nem engedélyezett kimenő forgalom módosításait, hogy a platformcsapat a szükséges forgalom támogatásához hozzáadhatja a folyamatot a tűzfalhoz, a Virtual Network Managerhez vagy más összetevőkhöz. Ezzel szemben, ha a korábban engedélyezett kimenő forgalomra már nincs szükség, a platformcsapatnak blokkolnia kell ezt a folyamatot a számítási feladat biztonságának fenntartása érdekében. Emellett közölheti a más virtuális hálózatokhoz vagy helyek közötti végpontokhoz vagy az architektúra összetevőinek változásaihoz való útválasztás változásait is. Minden erőforrásra szabályzatok és potenciálisan kimenő tűzfal-vezérlés vonatkozik.

Megbízhatóság

Ez az architektúra megfelel az alaparchitektúra megbízhatósági garanciáinak.

Megbízhatósági célok

A maximális lehetséges összetett SLO alacsonyabb, mint az alapkonfigurációs összetett SLO az olyan összetevők miatt, mint a kimenő hálózat vezérlése. Ezek a célzóna-környezetekben gyakran használt összetevők nem egyediek ebben az architektúrában. Az SLO hasonlóképpen csökken, ha a számítási feladatokkal foglalkozó csapat közvetlenül irányítja ezeket az Azure-szolgáltatásokat.

A lehető legnagyobb SLO ellenére a fő megbízhatósági szempont a számítási feladatok összetevőinek funkcionális csapatok közötti megosztása. Ezzel a módszerrel a számítási feladatokért felelős csapat egy speciális csapattal rendelkezik, amely a számítási feladat és más számítási feladatok által használt kritikus infrastruktúra üzemeltetésére összpontosít.

További információ: Javaslatok a megbízhatósági célok meghatározásához.

Kritikus függőségek

A számítási feladat által a platformon és az alkalmazás kezdőzónájában végrehajtott összes funkció megtekintése függőségként. Az incidenskezelési tervek megkövetelik, hogy a számítási feladatok csapata tisztában legyen a függőségekkel kapcsolatos kapcsolattartási ponttal és módszerrel. Ezeket a függőségeket is belefoglalja a számítási feladat hibamódjának elemzésébe (FMA).

Ebben az architektúrában vegye figyelembe a következő függőségeket:

• Kimenő tűzfal: A több számítási feladat által megosztott központi kimenő tűzfal a számítási feladathoz nem kapcsolódó változásokon megy keresztül.

• Hálózati portok kimerülése: A hálózati eszközt megosztó összes számítási feladat kihasználtságának kiugró száma hálózati telítettséghez vagy portkimerüléshez vezethet a kimenő tűzfalon.

• DINE-szabályzatok: Az Azure DNS privát DNS-zónáira (vagy bármely más platform által biztosított függőségre) vonatkozó DINE-szabályzatok a legjobbak, és nincs SLA a végrehajtás során. A DNS-konfiguráció késése késést okozhat az alkalmazások készenlétében a forgalom kezelésére.

• Felügyeleti csoportszabályzatok: A környezetek közötti konzisztens szabályzatok kulcsfontosságúak a megbízhatóság szempontjából. Győződjön meg arról, hogy az üzem előtti környezetek hasonlóak az éles környezetekhez, hogy pontos tesztelést biztosítsanak, és megakadályozzák a környezetspecifikus eltéréseket, amelyek blokkolhatják az üzembe helyezést vagy a skálázást. További információ: Alkalmazásfejlesztési környezetek kezelése az Azure-beli kezdőzónákban.

Ezen szempontok közül sok az Azure-beli kezdőzónák nélkül is létezhet, de a számítási feladatok és a platformcsapatok együttműködésen alapuló módon kell kezelniük ezeket a problémákat az igények kielégítése érdekében.

További információ: Javaslatok hibamód-elemzés végrehajtásához.

Biztonság

Az architektúra biztonsági szempontjai átviendők az alaparchitektúra alapján. A következő szakaszokban szereplő javaslatok a Well-Architected Framework biztonsági tervezési felülvizsgálati ellenőrzőlistáján alapulnak.

Hálózati vezérlők

Megfelelően konfigurálja a hálózati vezérlőket a számítási feladatok biztonságossá tételéhez.

Bejövő forgalom

A számítási feladatokat elkülönítheti a szervezet más munkaterhelési küllőitől az alhálózatokon található NSG-ken, illetve a regionális központ nem tranzitív jellegén vagy vezérlőin keresztül. Olyan átfogó NSG-k létrehozása, amelyek csak az alkalmazás és az infrastruktúra bejövő hálózati követelményeit teszik lehetővé. Azt javasoljuk, hogy ne kizárólag a központi hálózat nem tranzitív jellegére támaszkodik a biztonság érdekében.

A platformcsapat valószínűleg azure-szabályzatokat implementál annak biztosítására, hogy az Application Gateway webalkalmazási tűzfala letiltási módra legyen beállítva, korlátozza az előfizetés számára elérhető nyilvános IP-címek számát és egyéb ellenőrzéseket. Ezen szabályzatok mellett a számítási feladatokért felelős csapatnak kell felelősnek lennie a munkaterhelés-központú szabályzatok üzembe helyezéséért, amelyek megerősítik a bejövő biztonsági helyzetet.

Az alábbi táblázat példákat mutat be az architektúra bejövő vezérlőire.

Forrás	Cél	Számítási feladatok vezérlése	Platformvezérlés
Internet	Felhasználói forgalom folyamatai	Az NSG-n, a webalkalmazási tűzfalon és az útválasztási szabályokon keresztüli összes kérést tölcsérbe irányítja, mielőtt lehetővé tenné, hogy a nyilvános forgalom az előtérbeli virtuális gépekre irányuló magánforgalomra váltson	Egyik sem
Azure Bastion	Operátori hozzáférés virtuális gépekhez	NSG a virtuálisgép-alhálózatokon, amelyek blokkolják a távelérési portok felé érkező összes forgalmat, kivéve, ha az a platform kijelölt Azure Bastion-alhálózatából származik	Egyik sem
Egyéb küllők	Egyik sem	NSG-szabályokkal letiltva	Nem tranzitív útválasztási vagy Azure Firewall-szabályok az Azure Virtual WAN által védett központ esetén

Kimenő forgalom

Alkalmazza azokat az NSG-szabályokat, amelyek a megoldás szükséges kimenő kapcsolati követelményeit fejezik ki, és minden mást elutasítanak. Ne csak a központi hálózati vezérlőkre hagyatkozz. Számítási feladatokat végző operátorként önnek kell leállítania a nem kívánt kimenő forgalmat a lehető legközelebb a forráshoz.

Vegye figyelembe, hogy bár Ön a virtuális hálózaton belüli alhálózat tulajdonosa, a platformcsapat valószínűleg olyan tűzfalszabályokat hozott létre, amelyek kifejezetten a rögzített követelményeket képviselik a előfizetéses értékesítés folyamat részeként. Győződjön meg arról, hogy az alhálózatok és az erőforrás-elhelyezés változásai az architektúra teljes élettartama alatt továbbra is kompatibilisek az eredeti kéréssel. Vagy együttműködhet a hálózati csapattal a minimális hozzáférésű kimenő forgalom szabályozásának folytonossága érdekében.

Az alábbi táblázat példákat mutat be az architektúra kimenő forgalmára.

Végpont	Cél	Számítási feladatok (NSG) vezérlése	Platform (központ) vezérlő
ntp.ubuntu.com	A Linux rendszerű virtuális gépek hálózati időprotokollja (NTP)	UDP/123 az internetre az előtérbeli virtuálisgép-alhálózaton (a kimenő tűzfal szűkíti ezt a széles nyitás)	A tűzfal hálózati szabálykerete ugyanaz, mint a számítási feladatok vezérlése
Windows Update-végpontok	Windows Update-funkciók a Microsoft-kiszolgálókról	TCP/443 és TCP/80 az internetre a háttérbeli virtuálisgép-alhálózaton (a kimenő tűzfal szűkíti ezt a széles nyitás)	Tűzfal-kibocsátási szabály teljes tartománynévvel WindowsUpdate
Ügynökvégpontok figyelése	Szükséges forgalom a virtuális gépek monitorozási bővítményéhez	TCP/443 az internetre mindkét virtuálisgép-alhálózaton (a kimenő tűzfal szűkíti ezt a széles nyílást)	Szükséges tűzfalalkalmazási szabályok a TCP/443-on található összes meghatározott teljes tartománynévhez
nginx.org	Az Nginx (példaalkalmazás-összetevő) telepítése közvetlenül a szállítótól	TCP/443 az internetre az előtérbeli virtuálisgép-alhálózaton (a kimenő tűzfal szűkíti ezt a széles nyitás)	A TCP/443-on nginx.org szükséges tűzfalalkalmazási szabálykerete
Key Vault	TLS-tanúsítványok importálása (Transport Layer Security) az Application Gatewayben és a virtuális gépeken	- TCP/443 egy privát végpont alhálózatára mindkét virtuálisgép-alhálózatról egy privát végpont alhálózatára - TCP/443 egy privát végpont alhálózatára egy Application Gateway-alhálózatból - TCP/443 szükséges alkalmazásbiztonsági csoport (ASG) megjelöléssel és Application Gateway-alhálózattal megjelölt virtuális gépekről	Egyik sem

DDoS Protection

Határozza meg, hogy ki felel a megoldás összes nyilvános IP-címére kiterjedő DDoS Protection-terv alkalmazásáért. A platformcsapat IP-védelmi csomagokat használhat, vagy akár az Azure Policyt is használhatja a virtuális hálózati védelmi csomagok kényszerítéséhez. Ennek az architektúrának lefedettséggel kell rendelkeznie, mert nyilvános IP-címet igényel az internetről való bejövő forgalomhoz.

További információ: Javaslatok a hálózatkezeléssel és a kapcsolattal kapcsolatban.

Titkos kódok kezelése

A titkos kódok kezeléséhez ez az architektúra az alaparchitektúrát követi.

Számítási feladatokért felelős csapatként folytassa a titkos kulcsok megőrzését a Key Vault-példányban. Szükség szerint helyezzen üzembe további példányokat az alkalmazás- és infrastruktúra-műveletek támogatásához.

További információ: Javaslatok az alkalmazás titkos kulcsainak védelméről.

Költségoptimalizálás

A számítási feladatok erőforrásaira az alaparchitektúra költségoptimalizálási stratégiái is vonatkoznak erre az architektúrára.

Ez az architektúra nagy mértékben kihasználja az Azure célzónaplatform erőforrásait. Még akkor is, ha ezeket az erőforrásokat egy költségvisszatérítési modellel használja, a hozzáadott biztonság és a helyek közötti kapcsolat költséghatékonyabb, mint az erőforrások önkiszolgáló kezelése.

A platformcsapat az alábbi erőforrásokat kezeli ebben az architektúrában. Ezek az erőforrások gyakran használatalapúak (díjvisszatérítés), vagy akár ingyenesek a számítási feladatokért felelős csapat számára.

• Azure Firewall
• Biztonságiadat- és eseménykezelés (SIEM)
• Azure Bastion-gazdagépek
• Helyszíni kapcsolatok, például ExpressRoute

Használja ki a platformcsapat egyéb központosított ajánlatait, hogy ezeket az előnyöket az SLO, a helyreállítási idő célkitűzése (RTO) vagy a helyreállítási pont célkitűzése (RPO) veszélyeztetése nélkül terjessze ki a számítási feladatra.

További információ: Javaslatok a költségadatok gyűjtéséről és áttekintéséről.

A forgatókönyv üzembe helyezése

Ennek a referenciaarchitektúrának egy üzemelő példánya elérhető a GitHubon.

Következő lépés

Tekintse át a számítási feladatokért felelős csapat és a platformcsapatok között megosztott együttműködést és technikai részleteket.

Előfizetés-automatika