Azure Virtual Machines alaparchitektúra Azure célzónában

Azure Bastion

Azure Firewall

Azure Log Analytics

Azure Virtual Machines

Azure Virtual Network

A cikkben szereplő architektúra kibővül a virtual machine (VM) alaparchitektúrával az Azure célzónában való üzembe helyezéskor bekövetkező változások és elvárások kezelése érdekében.

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 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. A platformcsapatra vonatkozó javaslatok meg vannak adva.

Fontos

Mik azok az Azure leszállási zónák? Azure kezdőzónák két szemszögből szemléltetik a szervezet felhőbeli lábnyomát. Minden számítási feladat egyetlen munkaterhelési leszálló zónával rendelkezik, amely tartalmazza az összes környezetét, például a fejlesztést, a tesztelést és az éles környezetet. Minden környezet egy vagy több Azure előfizetésből áll. A munkaterhelés landing zone-ja a szervezet megosztott erőforrásaihoz csatlakozik. Ezen a kapcsolaton keresztül hozzáférhet a számítási feladatot futtató alapszintű infrastruktúrához, például a hálózatkezeléshez, az identitáshozzáférés-kezeléshez, a szabályzatokhoz és a figyeléshez. A platform kezdőzónája különböző előfizetések gyűjteménye, amelyek mindegyike egy adott függvénnyel rendelkezik. A kapcsolati előfizetések például központosított dns-feloldást, helyek közötti kapcsolatot és hálózati virtuális berendezéseket (NVA-kat) biztosítanak, amelyeket az alkalmazáscsapatok használhatnak.

Javasoljuk, hogy ismerje meg a Azure célzónák fogalmát, hogy felkészülhessen az architektúra megvalósítására.

Cikk elrendezése

Építészet	Tervezési döntés	Jól kiépítésű keretrendszer 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 ▪ Hálózattervezési változások az alapkonfigurációtól ▪ Ellenőrző ▪ Javítási megfelelőség ▪ Szervezeti irányítás ▪ Változáskezelés	▪ Megbízhatóság ▪ Biztonság ▪ Költségoptimalizálás

Építészet

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

Összetevők

Minden Azure célzóna-architektúrának külön tulajdonosi viszonya 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.

Munkaterhelés csapat által tulajdonolt erőforrások

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

• Azure Virtual Machines egy szolgáltatásként nyújtott infrastruktúra (IaaS), amely méretezhető számítási erőforrásokat biztosít. Ebben az architektúrában a virtuális gépek az előtérbeli és a háttérszinteket üzemeltetik, és a rugalmasság érdekében el vannak osztva a rendelkezésre állási zónák között.

• Azure Load Balancer a Transmission Control Protocol (TCP) és a User Datagram Protocol (UDP) forgalom 4. rétegbeli terheléselosztási szolgáltatása. Ebben az architektúrában egy belső terheléselosztó osztja el a forgalmat az előtérbeli és a háttérbeli virtuális gépek között a zónák között.

• Azure Application Gateway egy 7. rétegbeli fordított proxy és webes forgalom terheléselosztója. Ebben az architektúrában leállítja a Transport Layer Security (TLS) protokollt, ellenőrzi a kérelmeket, és fordított proxyként szolgál a felhasználói forgalom előtérbeli virtuális gépekre való átirányításához. A kiválasztott termékváltozat Azure Web Application Firewall is üzemeltet, hogy megvédje az előtérbeli virtuális gépeket a potenciálisan rosszindulatú forgalomtól.

• Azure Key Vault a titkos kulcsok, kulcsok és tanúsítványok kezelésére szolgáló szolgáltatás. Ebben az architektúrában az Application Gateway és a virtuális gépek által használt TLS-tanúsítványokat tárolja.

• A Azure Monitor, Log Analytics és Application Insights olyan eszközök, amelyek megfigyelhetőségi adatokat gyűjtenek, tárolnak és jelenítenek meg. Ebben az architektúrában összegyűjtik a vendég- és platformmetrikákat és -naplókat, betöltik és korrelálják őket egy dedikált munkaterületen, és lehetővé teszik az alkalmazásszintű telemetriát és vizualizációt a hibaelhárításhoz, a teljesítmény finomhangolásához és a szabályozáshoz.

• Azure Policy olyan szolgáltatás, amely kikényszeríti a szervezeti szabványokat, és nagy léptékben értékeli a megfelelőséget. Ebben az architektúrában a platformszintű szabályzatoktól elkülönítve alkalmazza a számítási feladatokra vonatkozó szabályozási vezérlőket.

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

• A küllős virtuális hálózati alhálózatok és a hálózati biztonsági csoportok (NSG-k) szegmentált IP-címteret és forgalomszűrési határokat biztosítanak. Ebben az architektúrában rétegalapú elkülönítést valósítanak meg, valamint vezérlik a számítási feladatok összetevőinek kelet-nyugati és bejövő/kimenő folyamatait.

• Private-végpontok privát IP-alapú hozzáférést biztosítanak a platformszolgáltatásokhoz a Azure gerincén keresztül. Ebben az architektúrában biztonságossá teszik a szolgáltatásként nyújtott platform (PaaS) megoldásokkal és az ezekhez a végpontokhoz szükséges privát DNS-zónákkal való kapcsolatot.

• Azure Managed Disks tartós, nagy teljesítményű tárterületet biztosít a virtuális gépek számára. Ebben az architektúrában naplófájlokat tárolnak a háttérkiszolgálókon, é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.

• Azure Firewall a központi hálózaton egy állapotalapú hálózati biztonsági szolgáltatás a forgalom szűréséhez és naplózásához. Ebben az architektúrában központilag ellenőrzi és korlátozza a küllőből érkező kimenő forgalmat kényszerített bújtatással. Ez az összetevő helyettesíti az alaparchitektúrában lévő nyilvános Azure Load Balancert, amely nem korlátozza az internet felé irányuló kimenő forgalmat.

• Azure Bastion a központi hálózaton olyan architekturális megközelítés, amely Távoli asztal Protokoll (RDP) és Secure Shell (SSH) kapcsolatot biztosít a TLS-en keresztüli virtuális gépekhez nyilvános IP-címek felfedése nélkül. Ebben az architektúrában megosztott, auditált üzemeltetési hozzáférést biztosít a számítási feladatokhoz használt virtuális gépekhez. Az alaparchitektúrában a számítási feladatokért felelős csapaté ez az összetevő.

• A leágazó virtuális hálózat egy elkülönített címtér, amely kölcsönös társviszonyban áll a központtal a központ által kínált megosztott szolgáltatások érdekében. Ebben az architektúrában a számítási feladatok, a bejövő forgalom és a kapcsolódó erőforrások a számítási feladatok csapatának kezelése alatt állnak.

• A felhasználó által definiált útvonalak (UDR-ek) olyan egyéni útválasztási szabályok, amelyekkel testre szabhatja az útválasztási táblákat, hogy adott következő ugrásokon keresztül irányíthassa a forgalmat. Ebben az architektúrában a küllőről érkező összes internethez kötött forgalmat a központ tűzfalán keresztül kényszerítik.

• Azure Policy-alapú szabályozási korlátozások és DeployIfNotExists (DINE) szabályzatok automatikusan üzembe helyezik vagy konfigurálják a megfelelőséghez szükséges erőforrásokat. Ebben az architektúrában biztosítják, hogy a kötelező platformhoz igazított konfigurációk, például a privát DNS vagy a diagnosztikák létezhessenek a számítási feladatok előfizetésében.

Fontos

Azure célzónák biztosítják a korábbi erőforrások egy részét a platform kezdőzónájának előfizetései részeként, a számítási feladat-előfizetés pedig más erőforrásokat is biztosít. Számos erőforrás része a kapcsolati előfizetésnek, amely további erőforrásokkal rendelkezik, például Azure ExpressRoute, Azure VPN Gateway és Azure DNS. Ezek a további erőforrások többhelyszínes hozzáférést és névfeloldást biztosítanak. Ezeknek az erőforrásoknak a kezelése a jelen cikk hatókörén kívül esik.

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

A workload landing zone kontextusában a számítási feladatokkal foglalkozó csapatnak tájékoztatnia kell a platformcsapatot a saját konkrét követelményeikről.

A számítási feladatokért felelős csapatának 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 platform csapata 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:

• Privát alkalmazások, például belső üzletági alkalmazások vagy kereskedelmi forgalomban kapható (COTS) megoldások, amelyek gyakran az Azure leszálló zónák Corp felügyeleti csoportja alatt 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.

A terhelési 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.

• A 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.

• Küllős hálózat mérete: Vegye figyelembe a működési követelményeket és a 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ő forráshálózati címfordítási (SNAT-) port legyen elérhető a kimerültség elkerülése érdekében. Nyilvános IP-címeket adhatnak a központi tűzfalhoz az SNAT-portkészlet kibontásához, vagy csatolhatnak egy Azure NAT Gateway az SNAT-kapacitás további skálázásához.

  Ezzel szemben, ha azt várja, hogy a számítási feladat minimális hálózati forgalmat generál (háttérzaj), 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 feladatnak vannak függőségei a Azure kívül? Ezek az információk fontosak a platform csapatának tudnia.

• A tűzfal konfiguráció: A platformcsapatnak tisztában kell lennie a sugárirányú hálózatot elhagyó és az alagúton keresztül a központi hálózatba jutó 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 Windows frissítésekhez a javítások megtartásához, a tűzfal nem tilthatja le 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.

• Operator-hozzáférés: Ha Microsoft Entra ID biztonsági csoportokat használnak az operátorok a virtuális gépek Azure Bastion keresztüli eléréséhez, tájékoztassa a platformcsapatot. Azure Bastion általában 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 a központi hálózaton Azure Bastion körüli NSG-k konfigurálásához.

• A nyilvános IP-címek: Tájékoztassa a platformcsapatot 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 ez a számítási feladatért felelős csapat feladata.

  Ebben az architektúrában egy másik nyilvános IP-cím érhető el a Azure Bastion keresztüli operatív 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.

Fontos

Javasoljuk, hogy a platformcsapat számára olyan előfizetés-átvételi munkafolyamatot biztosítsunk, amely a számítási feladatokkal foglalkozó csapat információinak rögzítésére szolgáló kérdések sorozatát foglalja magában. Ezek a kérdések szervezetenként eltérőek lehetnek, de a cél az előfizetések implementálására vonatkozó követelmények összegyűjtése. További információkért lásd az előfizetési automatát.

Virtuális gép tervezési opciók

A VM SKU és a lemezek kiválasztása változatlan marad az alaparchitektúrához képest.

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épeknéven is neveznek, amelyek a szervezet egészében való használatra lettek létrehozva.

A platformcsapat használhat felügyelt ajánlatot, például Azure Számítási gyűjteményt vagy egy privát adattárat 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 képek megfelelnek a munkaterhelés által támasztott szükséges üzleti követelményeknek.

Fontos

A platform csapatának: A Számítási gyűjtemény használata esetén a számítási feladatnak hálózati láthatóságra van szüksége a privát katalógushoz. Együttműködjön a munkaállomás-csapattal a biztonságos kapcsolat létrehozása érdekében.

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 ennek az architektúrának a Visio fájlját.

• Központi virtuális hálózat: A regionális központ olyan központosított szolgáltatásokat tartalmaz, amelyek az ugyanabban a régióban lévő számítási feladatok erőforrásaival kommunikálnak. További információ: platform csapat tulajdonában lévő erőforrások. Azt javasoljuk, hogy helyezze el a központot a kapcsolati előfizetésben.

• 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 csomópont hálózathoz van kapcsolva, amely tartalmazza a központosított szolgáltatásokat. A platform csapata birtokolja és kezeli ezt a küllős hálózatot. Ez a hálózat a számítási feladatok erőforrásokat tartalmazza. 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 platform csapatával, és rendszeresen tekintse át őket.

Fontos

A platformcsapat számára: Ha a számítási feladat nem igényli, ne kapcsolja össze közvetlenül a küllős hálózatot egy másik küllős virtuális hálózattal. Ez a gyakorlat védi a számítási feladat szegmentálási céljait. A csapatnak elő kell segítenie az összes tranzitív virtuális hálózati kapcsolatot.

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 a 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 munkaterhelést egy munkaterhelési landing zone-ban helyezi üzembe, akkor is hálózati vezérléseket 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 a 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 a 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 Azure Load Balancer 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 egy kimenő tűzfalon keresztül a társított központi hálózatra irányítják. A küllős hálózat összes lehetséges alhálózatához kapcsolódik 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 Tűzfalhoz irányítja.

Töltse le ennek az architektúrának a Visio fájlját.

A Key Vault privát végpontjához történő kommunikáció a munkafolyamatok esetében ugyanúgy történik, mint az alapvető architektúra esetében. 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 bejelentett kimenő forgalom valószínűleg meg van tagadva.

A kimenő forgalom szabályozása több, mint a várt forgalom engedélyezése. Arról is szól, hogy csak várt forgalom legyen engedélyezve. A nem kommunikált kimenő forgalom valószínűleg alapértelmezés szerint meg van tagadva, de a számítási feladat biztonságos működése érdekében fontos biztosítani, hogy a forgalom megfelelően legyen irányítva.

Tipp

Bátorítsa a platformcsapatot, hogy IP-csoportokat használjon a Azure Firewall. Ez a gyakorlat biztosítja, hogy a számítási feladatok kimenő forgalmának igényei pontosan meg legyenek jelölve, és csak a forrás alhálózatokra legyen szigorú hatóköre. Egy olyan szabály például, amely lehetővé teszi a munkaterhelés VM-jeinek api.example.org elérését, nem feltétlenül jelenti azt, hogy az ugyanazon a virtuális hálózaton belüli támogató erőforrások elérhetik ugyanazt a végpontot. Ez a részletes vezérlési szint javíthatja a hálózat biztonsági helyzetét.

Tájékoztassa a platformcsapatot az egyedi kimenő forgalomra vonatkozó követelményekről. A tűzfal forráshálózati címfordítást (SNAT) alkalmaz a kimenő folyamatokra, lecseréli a számítási feladat forrás IP-címét az egyik nyilvános IP-címére, a csatolt IP-címek száma pedig az SNAT-port költségvetését korlátozza. Ha a számítási feladat számos egyidejű kimenő kapcsolatot létesít, tájékoztassa a platformcsapatot, hogy egy Azure NAT Gateway csatolásával vagy több nyilvános IP-cím hozzáadásával enyhíthesse az SNAT-portok kimerülését a regionális tűzfalon. A tűzfal nyilvános IP-címkészletét is megoszthatja az alsóbb rétegbeli partnerekkel, így az engedélyezési listák a lehetséges forrás IP-címek teljes körét lefedik.

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 a Azure Policy használatával megtagadhatja a nyilvános IP-címeket a virtuálisgép-hálózati adaptereken (NIC-ken) és bármely más nyilvános IP-címen, a jól ismert bejövő pontokon kívül.

sajá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. A privát DNS-zónákat általában nagy méretekben kezelik DINE-szabályzatok segítségével, ami lehetővé teszi, hogy az Azure Firewall megbízható DNS-proxyként működjön, és támogassa a teljesen kiértékelt 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. Működjön együtt a platformcsapatával, hogy megértse elvárásaikat.

Kapcsolat tesztelése

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 Azure Network Watcher használatával.

Operátori hozzáférés

A baseline architektúrához hasonlóan a Azure Bastion 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 a Azure Bastion. A Azure célzónákat alkalmazó tipikus szervezeteknél központi erőforrásként helyezik üzembe Azure Bastion minden régióban. A platformcsapat birtokolja és tartja karban az Azure Bastiont, amelyet a szervezet összes számítási feladata közösen használ. A használati eset bemutatásához ebben az architektúrában a 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 a alaparchitektúra.

Jegyzet

Amikor az operátorok bejelentkeznek egy virtuális gépre, a vállalati identitásukat a Microsoft Entra ID bérlőjükben kell használniuk, és nem kell megosztaniuk a szolgáltatásneveket a különböző függvényekben.

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. 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 ismerteti. 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.

Megfigyelés

A 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 alapértelmezett architektúra.

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 Application Insights az alkalmazásteljesítmény-monitorozási (APM) szolgáltatás a számítási feladatokért felelős csapat számára.

• A Log Analytics munkaterület egységes fogadóként szolgál a munkaterület tulajdonában lévő Azure erőforrásokból és az alkalmazáskódból gyűjtött naplók és metrikák számára.

Töltse le ennek az architektúrának a 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 az Log Analytics munkaterületre, amelyet a számítási feladatokért felelős csapat 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. Azure 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 tároló adatainak korrelálása

A számítási feladat naplói és metrikái, valamint az infrastruktúra-összetevők a számítási feladat Log Analytics munkaterületén vannak tárolva. A központi szolgáltatások, például Azure Firewall, Microsoft Entra ID és 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 forrás adatainak korrelációjával kapcsolatban, győződjön meg arról, hogy az architektúra javítóriási dokumentációja foglalkozik vele, és tartalmazza a szervezeti kapcsolattartókat, ha a probléma túlnyúlik az erőforrások hatókörén. 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.

Fontos

A platformcsapat számára: Ahol lehetséges, adjon Azure szerepköralapú hozzáférés-vezérlést (Azure RBAC-t) a megfelelő platformerőforrások naplós fogadóinak lekérdezéséhez és olvasásához. Engedélyezze a tűzfalnaplókat a hálózati és alkalmazásszabály-értékelésekhez és a DNS-proxyhoz, mert az alkalmazáscsapatok a hibaelhárítási feladatok során felhasználhatják ezeket az információkat.

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ályokat a munkaterhelési landing zone-előfizetésben történő automatizált üzembe helyezések 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.

Fontos

Azure célzónák különböző DINE-szabályzatokat használnak, például egy olyan szabályzatot, amely nagy léptékben kezeli a privát végpontokat. Ez a szabályzat figyeli a privát végpontok telepítéseit és frissítéseit, valamint frissíti az Azure DNS-t a központi hálózaton, amely egy platform által felügyelt előfizetés részét képezi. A számítási feladatokat végző csapat nem rendelkezik engedéllyel a házirend módosítására a központban, és a platformcsapat nem figyeli a számítási feladatokat végző csapatok üzembe helyezését a DNS automatikus frissítéséhez. A rendszer DINE-szabályzatokkal biztosítja ezt a kapcsolatot.

Más szabályzatok is érinthetik ezt az architektúrát, beleértve a következő szabályzatokat:

• Active Directory tartományhoz való csatlakozáshoz Windows virtuális gép szükséges. Ez a szabályzat biztosítja, hogy a JoinADDomainExtension virtuálisgép-bővítmény telepítve és konfigurálva legyen. További információ: Enforce Windows virtuális gépek csatlakoztatása Active Directory tartományhoz.
• Ip-továbbítás letiltása hálózati adaptereken.

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 végrehajtja a módosításokat, felkészíti a felhasználókat és alkalmazza a költségellenőrzéseket. 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: A Azure házirendek módosítása hatással lehet a számítási feladatok erőforrásaira és függőségeire. Előfordulhat például, hogy közvetlen szabályzatmódosítások vagy a célterület áthelyezése egy új felügyeleti csoport 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 mind a kimenő Azure tűzfalra, mind a Azure Virtual Network Manager alkalmazott NSG-szabályokra vonatkoznak.

• 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ózatban: A hub útválasztásának tranzitív jellegében bekövetkező változások 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: A 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ázatának változásai hatékony rutinos, eseti és vészhelyzeti hozzáférést biztosítanak.

• Tulajdonosváltozások: A tulajdonosi és kapcsolattartási pontok változásainak közlése a számítási feladat csapatának, 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: Figyelje a hálózati kimenő forgalom jelentős növekedését, hogy a terhelés ne váljon zavaró szomszéddá 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 minősítési: 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.

Üzleti munkaterhelési 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érjük, közölje például a korábban nem engedélyezett kimenő forgalom módosításait, hogy a platform csapata hozzáadhassa ezt a forgalmat a tűzfalhoz, a Virtual Network Managerhez vagy más összetevőkhöz a szükséges forgalom támogatásához. 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 az útválasztás változásait más virtuális hálózatok, helyek közötti végpontok vagy az architektúra összetevőinek módosításai esetén is. Minden erőforrásra szabályzatok és potenciálisan kimenő tűzfal-vezérlés vonatkozik.

Megfontolások

Ezek a szempontok implementálják a Azure Well-Architected-keretrendszer alappilléreit, amely a számítási feladatok minőségének javítására használható vezérelvek halmaza. További információ: Microsoft Azure Well-Architected Framework.

Megbízhatóság

A megbízhatóság biztosítja, hogy az alkalmazás megfeleljen az ügyfelek felé vállalt kötelezettségeknek. További információ: Megbízhatóságitervezési felülvizsgálati ellenőrzőlistája.

Ez az architektúra megfelel az alaparchitektúramegbí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 a Azure szolgáltatásokat.

Bár a maximálisan elérhető SLO alacsonyabb, a fő megbízhatósági szempont a munkaterhelés ö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ókért tekintse meg a megbízhatósági célok meghatározására vonatkozó javaslatokat.

Kritikus függőségek

Tekintse meg a számítási feladat által a platformon és a számítási feladat leszállózónájában végrehajtott összes funkciót függőségként. Az incidenskezelési tervek megkövetelik, hogy a munkaterhelési csapat tisztában legyen ezekhez a függőségekhez tartozó kapcsolattartási pontot és módszert illetően. 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 feladattól független 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 portkihasználtsághoz vezethet a kimenő tűzfalon.

• DINE-szabályzatok: Az Azure DNS privát DNS-zónákra (vagy bármely más platform által biztosított függőségre) vonatkozó DINE-szabályzatok maximális erőfeszítést jelentenek, és nincs biztosítva SLA a végrehajtásra. 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 csoport házirendjei: A környezetek közötti konzisztens házirendek 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ás-fejlesztési környezetek kezelése Azure célzónákban.

Számos ilyen szempont létezhet Azure célzóna nélkül is, de a számítási feladatok és a platform csapatainak együttműködésben kell kezelniük ezeket a problémákat az igények kielégítése érdekében.

További információkat a Hibamód-elemzés végrehajtására vonatkozó javaslatok alatt találhat.

Biztonság

A biztonság biztosítékokat nyújt a szándékos támadások és az értékes adatokkal és rendszerekkel való visszaélés ellen. További információkért lásd a Biztonsági terv felülvizsgálati ellenőrzőlistát.

Az architektúra biztonsági szempontjai átkerülnek az alaparchitektúrából. A következő szakaszokban szereplő javaslatok a Well-Architected Keretrendszer biztonsági terv 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 ágaitól az alhálózatokon található NSG-ken, illetve a regionális központ nem áthatoló jellegén vagy ellenőrző mechanizmusain 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ása érdekében, hogy az Application Gateway Web Application Firewall deny módra legyen állítva az előfizetéshez elérhető nyilvános IP-címek számának és egyéb ellenőrzéseknek a korlátozásához. Ezen szabályzatok mellett a munkaterhelési csapat legyen felelős a munkaterhelésre fókuszáló szabályzatok bevezetéséért, amelyek megerősítik a bejövő forgalom biztonsági helyzetét.

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

Forrás	Cél	Munkaterhelés vezérlése	Platformfelügyelet
internet	Felhasználói forgalom folyamatai	Az összes kérést az NSG-n, Web Application Firewall-en és az útválasztási szabályokon keresztül irányítja, mielőtt lehetővé tenné, hogy a nyilvános forgalom áttérjen a magánforgalomba, amely belép az elülső virtuális gépekbe.	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ás vagy Azure Firewall szabályok egy Azure Virtual WAN 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. Tehermunkákat végző operátorként önnek kell leállítania a nem kívánt kimenő forgalmat a lehető legközelebb a forráshoz.

Figyeljen arra, hogy bár Ön a virtuális hálózaton belüli alhálózatok tulajdonosa, a platformcsapat valószínűleg olyan tűzfalszabályokat hozott létre, amelyek kifejezetten az Ön által rögzített követelményeket képviselik az előfizetés-kezelési 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 egressziós forgalmára.

Végpont	Cél	Munkaterhelés (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 a front-end-hez tartozó virtuális gép-alhálózaton (a kimenő forgalom tűzfala szűkíti ezt a széles megnyitást)	A tűzfal hálózati szabályának engedélyezése megegyezik a munkaterhelés vezérlésével.
Windows Update végpontok	Windows Update funkció a Microsoft szervereiről	TCP/443 és TCP/80 az internet felé a háttérbeli VM alhálózaton (a kimenő tűzfal szűkíti ezt a széles kimenetet)	Tűzfalkeret-szabály a WindowsUpdate teljes tartománynevével
Ü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 nyitott kapcsolatot)	Szükséges tűzfalalkalmazási szabályok a TCP/443-összes meghatározott teljes tartománynevéhez
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őoldali virtuális gép alhálózaton (a kimenő tűzfal szűkíti ezt a széles megnyitást)	Szükséges a tűzfal szabályainak engedélyezése a(z) nginx.org számára TCP/443 esetén.
Key Vault	TLS-tanúsítványok importálása 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ózatról - TCP/443 a szükséges alkalmazásbiztonsági csoporttal (ASG) címkézett és az Application Gateway alhálózatba tartozó virtuális gépekről	Egyik sem

DDoS elleni védelem

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 Azure Policy is használhat 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éshez és a kapcsolathoz.

Titkos kódok kezelése

A titkos kódok kezeléséhez ez az architektúra az alaparchitektúra 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ére.

Költségoptimalizálás

A költségoptimalizálás a szükségtelen kiadások csökkentésének és a működési hatékonyság javításának módjairól szól. További információt a Költségoptimalizálás tervezési felülvizsgálati ellenőrzőlistájában talál.

A számítási feladatok erőforrásai esetében 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 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ági információk és eseménykezelés (SIEM)
• Azure Bastion hostok
• Több telephely közötti kapcsolódás, 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ó: Költségadatok gyűjtésére és áttekintésére vonatkozó javaslatok.

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

A cikkben szereplő architektúra kibővül a virtual machine (VM) alaparchitektúrával az Azure célzónában való üzembe helyezéskor bekövetkező változások és elvárások kezelése érdekében.

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 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. A platformcsapatra vonatkozó javaslatok meg vannak adva.

Fontos

Mik azok az Azure leszállási zónák? Azure kezdőzónák két szemszögből szemléltetik a szervezet felhőbeli lábnyomát. Minden számítási feladat egyetlen munkaterhelési leszálló zónával rendelkezik, amely tartalmazza az összes környezetét, például a fejlesztést, a tesztelést és az éles környezetet. Minden környezet egy vagy több Azure előfizetésből áll. A munkaterhelés landing zone-ja a szervezet megosztott erőforrásaihoz csatlakozik. Ezen a kapcsolaton keresztül hozzáférhet a számítási feladatot futtató alapszintű infrastruktúrához, például a hálózatkezeléshez, az identitáshozzáférés-kezeléshez, a szabályzatokhoz és a figyeléshez. A platform kezdőzónája különböző előfizetések gyűjteménye, amelyek mindegyike egy adott függvénnyel rendelkezik. A kapcsolati előfizetések például központosított dns-feloldást, helyek közötti kapcsolatot és hálózati virtuális berendezéseket (NVA-kat) biztosítanak, amelyeket az alkalmazáscsapatok használhatnak.

Javasoljuk, hogy ismerje meg a Azure célzónák fogalmát, hogy felkészülhessen az architektúra megvalósítására.

Cikk elrendezése

Építészet	Tervezési döntés	Jól kiépítésű keretrendszer 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 ▪ Hálózattervezési változások az alapkonfigurációtól ▪ Ellenőrző ▪ Javítási megfelelőség ▪ Szervezeti irányítás ▪ Változáskezelés	▪ Megbízhatóság ▪ Biztonság ▪ Költségoptimalizálás

Építészet

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

Összetevők

Minden Azure célzóna-architektúrának külön tulajdonosi viszonya 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.

Munkaterhelés csapat által tulajdonolt erőforrások

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

• Azure Virtual Machines egy szolgáltatásként nyújtott infrastruktúra (IaaS), amely méretezhető számítási erőforrásokat biztosít. Ebben az architektúrában a virtuális gépek az előtérbeli és a háttérszinteket üzemeltetik, és a rugalmasság érdekében el vannak osztva a rendelkezésre állási zónák között.

• Azure Load Balancer a Transmission Control Protocol (TCP) és a User Datagram Protocol (UDP) forgalom 4. rétegbeli terheléselosztási szolgáltatása. Ebben az architektúrában egy belső terheléselosztó osztja el a forgalmat az előtérbeli és a háttérbeli virtuális gépek között a zónák között.

• Azure Application Gateway egy 7. rétegbeli fordított proxy és webes forgalom terheléselosztója. Ebben az architektúrában leállítja a Transport Layer Security (TLS) protokollt, ellenőrzi a kérelmeket, és fordított proxyként szolgál a felhasználói forgalom előtérbeli virtuális gépekre való átirányításához. A kiválasztott termékváltozat Azure Web Application Firewall is üzemeltet, hogy megvédje az előtérbeli virtuális gépeket a potenciálisan rosszindulatú forgalomtól.

• Azure Key Vault a titkos kulcsok, kulcsok és tanúsítványok kezelésére szolgáló szolgáltatás. Ebben az architektúrában az Application Gateway és a virtuális gépek által használt TLS-tanúsítványokat tárolja.

• A Azure Monitor, Log Analytics és Application Insights olyan eszközök, amelyek megfigyelhetőségi adatokat gyűjtenek, tárolnak és jelenítenek meg. Ebben az architektúrában összegyűjtik a vendég- és platformmetrikákat és -naplókat, betöltik és korrelálják őket egy dedikált munkaterületen, és lehetővé teszik az alkalmazásszintű telemetriát és vizualizációt a hibaelhárításhoz, a teljesítmény finomhangolásához és a szabályozáshoz.

• Azure Policy olyan szolgáltatás, amely kikényszeríti a szervezeti szabványokat, és nagy léptékben értékeli a megfelelőséget. Ebben az architektúrában a platformszintű szabályzatoktól elkülönítve alkalmazza a számítási feladatokra vonatkozó szabályozási vezérlőket.

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

• A küllős virtuális hálózati alhálózatok és a hálózati biztonsági csoportok (NSG-k) szegmentált IP-címteret és forgalomszűrési határokat biztosítanak. Ebben az architektúrában rétegalapú elkülönítést valósítanak meg, valamint vezérlik a számítási feladatok összetevőinek kelet-nyugati és bejövő/kimenő folyamatait.

• Private-végpontok privát IP-alapú hozzáférést biztosítanak a platformszolgáltatásokhoz a Azure gerincén keresztül. Ebben az architektúrában biztonságossá teszik a szolgáltatásként nyújtott platform (PaaS) megoldásokkal és az ezekhez a végpontokhoz szükséges privát DNS-zónákkal való kapcsolatot.

• Azure Managed Disks tartós, nagy teljesítményű tárterületet biztosít a virtuális gépek számára. Ebben az architektúrában naplófájlokat tárolnak a háttérkiszolgálókon, é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.

• Azure Firewall a központi hálózaton egy állapotalapú hálózati biztonsági szolgáltatás a forgalom szűréséhez és naplózásához. Ebben az architektúrában központilag ellenőrzi és korlátozza a küllőből érkező kimenő forgalmat kényszerített bújtatással. Ez az összetevő helyettesíti az alaparchitektúrában lévő nyilvános Azure Load Balancert, amely nem korlátozza az internet felé irányuló kimenő forgalmat.

• Azure Bastion a központi hálózaton olyan architekturális megközelítés, amely Távoli asztal Protokoll (RDP) és Secure Shell (SSH) kapcsolatot biztosít a TLS-en keresztüli virtuális gépekhez nyilvános IP-címek felfedése nélkül. Ebben az architektúrában megosztott, auditált üzemeltetési hozzáférést biztosít a számítási feladatokhoz használt virtuális gépekhez. Az alaparchitektúrában a számítási feladatokért felelős csapaté ez az összetevő.

• A leágazó virtuális hálózat egy elkülönített címtér, amely kölcsönös társviszonyban áll a központtal a központ által kínált megosztott szolgáltatások érdekében. Ebben az architektúrában a számítási feladatok, a bejövő forgalom és a kapcsolódó erőforrások a számítási feladatok csapatának kezelése alatt állnak.

• A felhasználó által definiált útvonalak (UDR-ek) olyan egyéni útválasztási szabályok, amelyekkel testre szabhatja az útválasztási táblákat, hogy adott következő ugrásokon keresztül irányíthassa a forgalmat. Ebben az architektúrában a küllőről érkező összes internethez kötött forgalmat a központ tűzfalán keresztül kényszerítik.

• Azure Policy-alapú szabályozási korlátozások és DeployIfNotExists (DINE) szabályzatok automatikusan üzembe helyezik vagy konfigurálják a megfelelőséghez szükséges erőforrásokat. Ebben az architektúrában biztosítják, hogy a kötelező platformhoz igazított konfigurációk, például a privát DNS vagy a diagnosztikák létezhessenek a számítási feladatok előfizetésében.

Fontos

Azure célzónák biztosítják a korábbi erőforrások egy részét a platform kezdőzónájának előfizetései részeként, a számítási feladat-előfizetés pedig más erőforrásokat is biztosít. Számos erőforrás része a kapcsolati előfizetésnek, amely további erőforrásokkal rendelkezik, például Azure ExpressRoute, Azure VPN Gateway és Azure DNS. Ezek a további erőforrások többhelyszínes hozzáférést és névfeloldást biztosítanak. Ezeknek az erőforrásoknak a kezelése a jelen cikk hatókörén kívül esik.

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

A workload landing zone kontextusában a számítási feladatokkal foglalkozó csapatnak tájékoztatnia kell a platformcsapatot a saját konkrét követelményeikről.

A számítási feladatokért felelős csapatának 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 platform csapata 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:

• Privát alkalmazások, például belső üzletági alkalmazások vagy kereskedelmi forgalomban kapható (COTS) megoldások, amelyek gyakran az Azure leszálló zónák Corp felügyeleti csoportja alatt 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.

A terhelési 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.

• A 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.

• Küllős hálózat mérete: Vegye figyelembe a működési követelményeket és a 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ő forráshálózati címfordítási (SNAT-) port legyen elérhető a kimerültség elkerülése érdekében. Nyilvános IP-címeket adhatnak a központi tűzfalhoz az SNAT-portkészlet kibontásához, vagy csatolhatnak egy Azure NAT Gateway az SNAT-kapacitás további skálázásához.

  Ezzel szemben, ha azt várja, hogy a számítási feladat minimális hálózati forgalmat generál (háttérzaj), 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 feladatnak vannak függőségei a Azure kívül? Ezek az információk fontosak a platform csapatának tudnia.

• A tűzfal konfiguráció: A platformcsapatnak tisztában kell lennie a sugárirányú hálózatot elhagyó és az alagúton keresztül a központi hálózatba jutó 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 Windows frissítésekhez a javítások megtartásához, a tűzfal nem tilthatja le 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.

• Operator-hozzáférés: Ha Microsoft Entra ID biztonsági csoportokat használnak az operátorok a virtuális gépek Azure Bastion keresztüli eléréséhez, tájékoztassa a platformcsapatot. Azure Bastion általában 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 a központi hálózaton Azure Bastion körüli NSG-k konfigurálásához.

• A nyilvános IP-címek: Tájékoztassa a platformcsapatot 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 ez a számítási feladatért felelős csapat feladata.

  Ebben az architektúrában egy másik nyilvános IP-cím érhető el a Azure Bastion keresztüli operatív 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.

Fontos

Javasoljuk, hogy a platformcsapat számára olyan előfizetés-átvételi munkafolyamatot biztosítsunk, amely a számítási feladatokkal foglalkozó csapat információinak rögzítésére szolgáló kérdések sorozatát foglalja magában. Ezek a kérdések szervezetenként eltérőek lehetnek, de a cél az előfizetések implementálására vonatkozó követelmények összegyűjtése. További információkért lásd az előfizetési automatát.

Virtuális gép tervezési opciók

A VM SKU és a lemezek kiválasztása változatlan marad az alaparchitektúrához képest.

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épeknéven is neveznek, amelyek a szervezet egészében való használatra lettek létrehozva.

A platformcsapat használhat felügyelt ajánlatot, például Azure Számítási gyűjteményt vagy egy privát adattárat 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 képek megfelelnek a munkaterhelés által támasztott szükséges üzleti követelményeknek.

Fontos

A platform csapatának: A Számítási gyűjtemény használata esetén a számítási feladatnak hálózati láthatóságra van szüksége a privát katalógushoz. Együttműködjön a munkaállomás-csapattal a biztonságos kapcsolat létrehozása érdekében.

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 ennek az architektúrának a Visio fájlját.

• Központi virtuális hálózat: A regionális központ olyan központosított szolgáltatásokat tartalmaz, amelyek az ugyanabban a régióban lévő számítási feladatok erőforrásaival kommunikálnak. További információ: platform csapat tulajdonában lévő erőforrások. Azt javasoljuk, hogy helyezze el a központot a kapcsolati előfizetésben.

• 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 csomópont hálózathoz van kapcsolva, amely tartalmazza a központosított szolgáltatásokat. A platform csapata birtokolja és kezeli ezt a küllős hálózatot. Ez a hálózat a számítási feladatok erőforrásokat tartalmazza. 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 platform csapatával, és rendszeresen tekintse át őket.

Fontos

A platformcsapat számára: Ha a számítási feladat nem igényli, ne kapcsolja össze közvetlenül a küllős hálózatot egy másik küllős virtuális hálózattal. Ez a gyakorlat védi a számítási feladat szegmentálási céljait. A csapatnak elő kell segítenie az összes tranzitív virtuális hálózati kapcsolatot.

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 a 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 munkaterhelést egy munkaterhelési landing zone-ban helyezi üzembe, akkor is hálózati vezérléseket 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 a 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 a 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 Azure Load Balancer 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 egy kimenő tűzfalon keresztül a társított központi hálózatra irányítják. A küllős hálózat összes lehetséges alhálózatához kapcsolódik 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 Tűzfalhoz irányítja.

Töltse le ennek az architektúrának a Visio fájlját.

A Key Vault privát végpontjához történő kommunikáció a munkafolyamatok esetében ugyanúgy történik, mint az alapvető architektúra esetében. 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 bejelentett kimenő forgalom valószínűleg meg van tagadva.

A kimenő forgalom szabályozása több, mint a várt forgalom engedélyezése. Arról is szól, hogy csak várt forgalom legyen engedélyezve. A nem kommunikált kimenő forgalom valószínűleg alapértelmezés szerint meg van tagadva, de a számítási feladat biztonságos működése érdekében fontos biztosítani, hogy a forgalom megfelelően legyen irányítva.

Tipp

Bátorítsa a platformcsapatot, hogy IP-csoportokat használjon a Azure Firewall. Ez a gyakorlat biztosítja, hogy a számítási feladatok kimenő forgalmának igényei pontosan meg legyenek jelölve, és csak a forrás alhálózatokra legyen szigorú hatóköre. Egy olyan szabály például, amely lehetővé teszi a munkaterhelés VM-jeinek api.example.org elérését, nem feltétlenül jelenti azt, hogy az ugyanazon a virtuális hálózaton belüli támogató erőforrások elérhetik ugyanazt a végpontot. Ez a részletes vezérlési szint javíthatja a hálózat biztonsági helyzetét.

Tájékoztassa a platformcsapatot az egyedi kimenő forgalomra vonatkozó követelményekről. A tűzfal forráshálózati címfordítást (SNAT) alkalmaz a kimenő folyamatokra, lecseréli a számítási feladat forrás IP-címét az egyik nyilvános IP-címére, a csatolt IP-címek száma pedig az SNAT-port költségvetését korlátozza. Ha a számítási feladat számos egyidejű kimenő kapcsolatot létesít, tájékoztassa a platformcsapatot, hogy egy Azure NAT Gateway csatolásával vagy több nyilvános IP-cím hozzáadásával enyhíthesse az SNAT-portok kimerülését a regionális tűzfalon. A tűzfal nyilvános IP-címkészletét is megoszthatja az alsóbb rétegbeli partnerekkel, így az engedélyezési listák a lehetséges forrás IP-címek teljes körét lefedik.

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 a Azure Policy használatával megtagadhatja a nyilvános IP-címeket a virtuálisgép-hálózati adaptereken (NIC-ken) és bármely más nyilvános IP-címen, a jól ismert bejövő pontokon kívül.

sajá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. A privát DNS-zónákat általában nagy méretekben kezelik DINE-szabályzatok segítségével, ami lehetővé teszi, hogy az Azure Firewall megbízható DNS-proxyként működjön, és támogassa a teljesen kiértékelt 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. Működjön együtt a platformcsapatával, hogy megértse elvárásaikat.

Kapcsolat tesztelése

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 Azure Network Watcher használatával.

Operátori hozzáférés

A baseline architektúrához hasonlóan a Azure Bastion 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 a Azure Bastion. A Azure célzónákat alkalmazó tipikus szervezeteknél központi erőforrásként helyezik üzembe Azure Bastion minden régióban. A platformcsapat birtokolja és tartja karban az Azure Bastiont, amelyet a szervezet összes számítási feladata közösen használ. A használati eset bemutatásához ebben az architektúrában a 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 a alaparchitektúra.

Jegyzet

Amikor az operátorok bejelentkeznek egy virtuális gépre, a vállalati identitásukat a Microsoft Entra ID bérlőjükben kell használniuk, és nem kell megosztaniuk a szolgáltatásneveket a különböző függvényekben.

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. 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 ismerteti. 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.

Megfigyelés

A 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 alapértelmezett architektúra.

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 Application Insights az alkalmazásteljesítmény-monitorozási (APM) szolgáltatás a számítási feladatokért felelős csapat számára.

• A Log Analytics munkaterület egységes fogadóként szolgál a munkaterület tulajdonában lévő Azure erőforrásokból és az alkalmazáskódból gyűjtött naplók és metrikák számára.

Töltse le ennek az architektúrának a 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 az Log Analytics munkaterületre, amelyet a számítási feladatokért felelős csapat 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. Azure 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 tároló adatainak korrelálása

A számítási feladat naplói és metrikái, valamint az infrastruktúra-összetevők a számítási feladat Log Analytics munkaterületén vannak tárolva. A központi szolgáltatások, például Azure Firewall, Microsoft Entra ID és 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 forrás adatainak korrelációjával kapcsolatban, győződjön meg arról, hogy az architektúra javítóriási dokumentációja foglalkozik vele, és tartalmazza a szervezeti kapcsolattartókat, ha a probléma túlnyúlik az erőforrások hatókörén. 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.

Fontos

A platformcsapat számára: Ahol lehetséges, adjon Azure szerepköralapú hozzáférés-vezérlést (Azure RBAC-t) a megfelelő platformerőforrások naplós fogadóinak lekérdezéséhez és olvasásához. Engedélyezze a tűzfalnaplókat a hálózati és alkalmazásszabály-értékelésekhez és a DNS-proxyhoz, mert az alkalmazáscsapatok a hibaelhárítási feladatok során felhasználhatják ezeket az információkat.

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ályokat a munkaterhelési landing zone-előfizetésben történő automatizált üzembe helyezések 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.

Fontos

Azure célzónák különböző DINE-szabályzatokat használnak, például egy olyan szabályzatot, amely nagy léptékben kezeli a privát végpontokat. Ez a szabályzat figyeli a privát végpontok telepítéseit és frissítéseit, valamint frissíti az Azure DNS-t a központi hálózaton, amely egy platform által felügyelt előfizetés részét képezi. A számítási feladatokat végző csapat nem rendelkezik engedéllyel a házirend módosítására a központban, és a platformcsapat nem figyeli a számítási feladatokat végző csapatok üzembe helyezését a DNS automatikus frissítéséhez. A rendszer DINE-szabályzatokkal biztosítja ezt a kapcsolatot.

Más szabályzatok is érinthetik ezt az architektúrát, beleértve a következő szabályzatokat:

• Active Directory tartományhoz való csatlakozáshoz Windows virtuális gép szükséges. Ez a szabályzat biztosítja, hogy a JoinADDomainExtension virtuálisgép-bővítmény telepítve és konfigurálva legyen. További információ: Enforce Windows virtuális gépek csatlakoztatása Active Directory tartományhoz.
• Ip-továbbítás letiltása hálózati adaptereken.

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 végrehajtja a módosításokat, felkészíti a felhasználókat és alkalmazza a költségellenőrzéseket. 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: A Azure házirendek módosítása hatással lehet a számítási feladatok erőforrásaira és függőségeire. Előfordulhat például, hogy közvetlen szabályzatmódosítások vagy a célterület áthelyezése egy új felügyeleti csoport 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 mind a kimenő Azure tűzfalra, mind a Azure Virtual Network Manager alkalmazott NSG-szabályokra vonatkoznak.

• 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ózatban: A hub útválasztásának tranzitív jellegében bekövetkező változások 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: A 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ázatának változásai hatékony rutinos, eseti és vészhelyzeti hozzáférést biztosítanak.

• Tulajdonosváltozások: A tulajdonosi és kapcsolattartási pontok változásainak közlése a számítási feladat csapatának, 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: Figyelje a hálózati kimenő forgalom jelentős növekedését, hogy a terhelés ne váljon zavaró szomszéddá 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 minősítési: 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.

Üzleti munkaterhelési 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érjük, közölje például a korábban nem engedélyezett kimenő forgalom módosításait, hogy a platform csapata hozzáadhassa ezt a forgalmat a tűzfalhoz, a Virtual Network Managerhez vagy más összetevőkhöz a szükséges forgalom támogatásához. 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 az útválasztás változásait más virtuális hálózatok, helyek közötti végpontok vagy az architektúra összetevőinek módosításai esetén is. Minden erőforrásra szabályzatok és potenciálisan kimenő tűzfal-vezérlés vonatkozik.

Megfontolások

Ezek a szempontok implementálják a Azure Well-Architected-keretrendszer alappilléreit, amely a számítási feladatok minőségének javítására használható vezérelvek halmaza. További információ: Microsoft Azure Well-Architected Framework.

Megbízhatóság

A megbízhatóság biztosítja, hogy az alkalmazás megfeleljen az ügyfelek felé vállalt kötelezettségeknek. További információ: Megbízhatóságitervezési felülvizsgálati ellenőrzőlistája.

Ez az architektúra megfelel az alaparchitektúramegbí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 a Azure szolgáltatásokat.

Bár a maximálisan elérhető SLO alacsonyabb, a fő megbízhatósági szempont a munkaterhelés ö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ókért tekintse meg a megbízhatósági célok meghatározására vonatkozó javaslatokat.

Kritikus függőségek

Tekintse meg a számítási feladat által a platformon és a számítási feladat leszállózónájában végrehajtott összes funkciót függőségként. Az incidenskezelési tervek megkövetelik, hogy a munkaterhelési csapat tisztában legyen ezekhez a függőségekhez tartozó kapcsolattartási pontot és módszert illetően. 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 feladattól független 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 portkihasználtsághoz vezethet a kimenő tűzfalon.

• DINE-szabályzatok: Az Azure DNS privát DNS-zónákra (vagy bármely más platform által biztosított függőségre) vonatkozó DINE-szabályzatok maximális erőfeszítést jelentenek, és nincs biztosítva SLA a végrehajtásra. 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 csoport házirendjei: A környezetek közötti konzisztens házirendek 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ás-fejlesztési környezetek kezelése Azure célzónákban.

Számos ilyen szempont létezhet Azure célzóna nélkül is, de a számítási feladatok és a platform csapatainak együttműködésben kell kezelniük ezeket a problémákat az igények kielégítése érdekében.

További információkat a Hibamód-elemzés végrehajtására vonatkozó javaslatok alatt találhat.

Biztonság

A biztonság biztosítékokat nyújt a szándékos támadások és az értékes adatokkal és rendszerekkel való visszaélés ellen. További információkért lásd a Biztonsági terv felülvizsgálati ellenőrzőlistát.

Az architektúra biztonsági szempontjai átkerülnek az alaparchitektúrából. A következő szakaszokban szereplő javaslatok a Well-Architected Keretrendszer biztonsági terv 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 ágaitól az alhálózatokon található NSG-ken, illetve a regionális központ nem áthatoló jellegén vagy ellenőrző mechanizmusain 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ása érdekében, hogy az Application Gateway Web Application Firewall deny módra legyen állítva az előfizetéshez elérhető nyilvános IP-címek számának és egyéb ellenőrzéseknek a korlátozásához. Ezen szabályzatok mellett a munkaterhelési csapat legyen felelős a munkaterhelésre fókuszáló szabályzatok bevezetéséért, amelyek megerősítik a bejövő forgalom biztonsági helyzetét.

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

Forrás	Cél	Munkaterhelés vezérlése	Platformfelügyelet
internet	Felhasználói forgalom folyamatai	Az összes kérést az NSG-n, Web Application Firewall-en és az útválasztási szabályokon keresztül irányítja, mielőtt lehetővé tenné, hogy a nyilvános forgalom áttérjen a magánforgalomba, amely belép az elülső virtuális gépekbe.	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ás vagy Azure Firewall szabályok egy Azure Virtual WAN 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. Tehermunkákat végző operátorként önnek kell leállítania a nem kívánt kimenő forgalmat a lehető legközelebb a forráshoz.

Figyeljen arra, hogy bár Ön a virtuális hálózaton belüli alhálózatok tulajdonosa, a platformcsapat valószínűleg olyan tűzfalszabályokat hozott létre, amelyek kifejezetten az Ön által rögzített követelményeket képviselik az előfizetés-kezelési 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 egressziós forgalmára.

Végpont	Cél	Munkaterhelés (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 a front-end-hez tartozó virtuális gép-alhálózaton (a kimenő forgalom tűzfala szűkíti ezt a széles megnyitást)	A tűzfal hálózati szabályának engedélyezése megegyezik a munkaterhelés vezérlésével.
Windows Update végpontok	Windows Update funkció a Microsoft szervereiről	TCP/443 és TCP/80 az internet felé a háttérbeli VM alhálózaton (a kimenő tűzfal szűkíti ezt a széles kimenetet)	Tűzfalkeret-szabály a WindowsUpdate teljes tartománynevével
Ü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 nyitott kapcsolatot)	Szükséges tűzfalalkalmazási szabályok a TCP/443-összes meghatározott teljes tartománynevéhez
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őoldali virtuális gép alhálózaton (a kimenő tűzfal szűkíti ezt a széles megnyitást)	Szükséges a tűzfal szabályainak engedélyezése a(z) nginx.org számára TCP/443 esetén.
Key Vault	TLS-tanúsítványok importálása 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ózatról - TCP/443 a szükséges alkalmazásbiztonsági csoporttal (ASG) címkézett és az Application Gateway alhálózatba tartozó virtuális gépekről	Egyik sem

DDoS elleni védelem

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 Azure Policy is használhat 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éshez és a kapcsolathoz.

Titkos kódok kezelése

A titkos kódok kezeléséhez ez az architektúra az alaparchitektúra 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ére.

Költségoptimalizálás

A költségoptimalizálás a szükségtelen kiadások csökkentésének és a működési hatékonyság javításának módjairól szól. További információt a Költségoptimalizálás tervezési felülvizsgálati ellenőrzőlistájában talál.

A számítási feladatok erőforrásai esetében 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 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ági információk és eseménykezelés (SIEM)
• Azure Bastion hostok
• Több telephely közötti kapcsolódás, 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ó: Költségadatok gyűjtésére és áttekintésére vonatkozó javaslatok.

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