Műveleti eljárások kritikus fontosságú számítási feladatokhoz az Azure-ban

A megbízható és hatékony műveleteknek az automatizálás alapelvein kell alapulnia , ahol csak lehetséges , és kódként kell konfigurálni. Ehhez a megközelítéshez jelentős mérnöki beruházásokra van szükség a DevOps-folyamatokban. Az automatizált folyamatok alkalmazás- és infrastruktúrakód-összetevők üzembe helyezésére szolgálnak. Ennek a megközelítésnek az előnyei közé tartoznak a konzisztens és pontos működési eredmények, minimális manuális üzemeltetési eljárásokkal.

Ez a tervezési terület a hatékony és konzisztens üzemeltetési eljárások megvalósítását mutatja be.

Fontos

Ez a cikk az Azure Well-Architected Framework kritikus fontosságú számítási feladatok sorozatának része. Ha nem ismeri ezt a sorozatot, javasoljuk, hogy kezdje a Mi az a kritikus fontosságú számítási feladat?.

DevOps-folyamatok

A DevOps egyetlen mérnöki funkcióba egyesíti a fejlesztési és üzemeltetési folyamatokat és a csapatokat. Ez magában foglalja az alkalmazás teljes életciklusát, és automatizálási és DevOps-eszközöket használ az üzembehelyezési műveletek gyors, hatékony és megbízható végrehajtásához. A DevOps-folyamatok támogatják és támogatják a folyamatos integrációt és a folyamatos teljesítést (CI/CD), miközben elősegítik a folyamatos fejlődés kultúráját.

A kritikus fontosságú alkalmazások DevOps-csapatának kell felelősnek lennie az alábbi feladatokért:

• Alkalmazás- és infrastruktúra-erőforrások létrehozása és kezelése CI/CD-automatizálással.
• Alkalmazásfigyelés és megfigyelhetőség.
• Azure-beli szerepköralapú hozzáférés-vezérlés (RBAC) és identitáskezelés az alkalmazásösszetevőkhöz.
• Alkalmazásösszetevők hálózatkezelése.
• Az alkalmazáserőforrások költségkezelése.

A DevSecOps kibővíti a DevOps-modellt a biztonsági monitorozás, az alkalmazásnaplók és a minőségbiztosítás integrálásával a fejlesztéssel és műveletekkel az alkalmazás teljes életciklusa során. DevOps-csapatokra van szükség a biztonsági szempontból érzékeny és szigorúan szabályozott forgatókönyvekhez, hogy a biztonság a fejlesztési életciklus során ne egy adott kiadási fázisban vagy kapuban legyen beépítve.

Kialakítási szempontok

• Kiadási és frissítési folyamat. Kerülje a manuális folyamatokat az alkalmazás-összetevők vagy a mögöttes infrastruktúra bármilyen módosításához. A manuális folyamatok inkonzisztens eredményekhez vezethetnek.

• Függőségek a központi informatikai csapatoktól. A DevOps-folyamatok nehezen alkalmazhatók, ha a központosított függvények szigorú függőségeket jelentenek, mivel ezek a függőségek megakadályozzák a végpontok közötti műveleteket.

• Identitás- és hozzáférés-kezelés. A DevOps-csapatok részletes Azure RBAC-szerepköröket vehetnek figyelembe különböző technikai funkciókhoz, például az AppDataOps adatbázis-kezeléshez. Nulla megbízhatósági modell alkalmazása DevOps-szerepkörökben.

Tervezési javaslatok

• Adja meg a konfigurációs beállításokat és a frissítéseket kódként. A változáskezelés kódon keresztüli alkalmazásával konzisztens kiadási és frissítési folyamatokat engedélyezhet, beleértve az olyan feladatokat, mint a kulcs- vagy titkos kulcsok rotálása és az engedélyek kezelése. A beépített automatikus frissítési mechanizmusok helyett használjon folyamat által felügyelt frissítési folyamatokat, például ütemezett folyamatfuttatásokat.

• Ne használjon központi folyamatokat vagy kiépítési folyamatokat az alkalmazáserőforrások példányosításához vagy kezeléséhez. Ezzel külső alkalmazásfüggőségeket és további kockázati vektorokat vezet be, például a zajos szomszédforgatókönyvekhez társítottakat.

  Ha központosított kiépítési folyamatokat kell használnia, győződjön meg arról, hogy a függőségek rendelkezésre állási követelményei teljes mértékben igazodnak a kritikus fontosságú követelményekhez. A központi csapatoknak átláthatóságot kell biztosítaniuk, hogy a végpontok közötti alkalmazás holisztikus üzembe helyezést érjen el.

• Az egyes futamok során a mérnöki kapacitás egy részét a platform alapvető fejlesztéseinek és megbízhatóságának növelése érdekében szenteljük. Javasoljuk, hogy a kapacitás 20–40 százalékát foglalja le ezekre a fejlesztésekre.

• Általános tervezési kritériumok, referenciaarchitektúrák és kódtárak kidolgozása, amelyek igazodnak az alapvető tervezési alapelvekhez. A megbízhatóság, a biztonság és a műveletek konzisztens alapkonfigurációjának kényszerítése a Azure Policy használó szabályzatalapú megközelítéssel.

  Használhatja a közös mérnöki feltételeket és a kapcsolódó összetevőket is, például az Azure-szabályzatokat és a Terraform-erőforrásokat a közös tervezési mintákhoz a szervezet szélesebb körű alkalmazás-ökoszisztémájában található egyéb számítási feladatok között.

• Nulla megbízhatósági modell alkalmazása kritikus alkalmazáskörnyezetekben. Az Microsoft Entra Privileged Identity Management-hez hasonló technológiák használatával biztosíthatja, hogy a műveletek konzisztensek legyenek, és csak CI/CD-folyamatokon vagy automatizált üzemeltetési eljárásokon keresztül történjenek.

  A csapattagoknak nem szabad állandó írási hozzáféréssel rendelkezniük semmilyen környezethez. Előfordulhat, hogy kivételeket szeretne tenni a fejlesztési környezetekben, hogy megkönnyítse a tesztelést és a hibakeresést.

• Vészhelyzeti folyamatok definiálása az éles környezetekhez való igény szerint történő hozzáféréshez. Győződjön meg arról, hogy a hitelesítési szolgáltatóval kapcsolatos súlyos problémák esetén a feltört üvegfiókok léteznek.

• Fontolja meg az AIOps használatát az üzemeltetési eljárások és az eseményindítók folyamatos fejlesztéséhez.

Alkalmazásműveletek

Az alkalmazástervezési és platformjavaslatok befolyásolják az üzemeltetési eljárásokat. A különböző Azure-szolgáltatások működési képességeket is biztosítanak, különösen a magas rendelkezésre állás és a helyreállítás érdekében.

Kialakítási szempontok

• Az Azure-szolgáltatások beépített műveletei. Az Azure-szolgáltatások beépített (alapértelmezés szerint engedélyezve) és konfigurálható platformképességeket biztosítanak, például a zónaredundanciát és a georeplikációt. Az alkalmazások megbízhatósága ezektől a műveletektől függ. Bizonyos konfigurálható képességek további költségekkel járnak, például az Azure Cosmos DB több írásos üzembehelyezési konfigurációja. Kerülje az egyéni megoldások létrehozását, hacsak nem feltétlenül szükséges.

• Működési hozzáférés és végrehajtási idő. A legtöbb szükséges művelet az Azure Resource Manager API-val vagy a Azure Portal keresztül érhető el. Bizonyos műveletekhez azonban támogatási mérnököknek kell segítséget nyújtaniuk. Például egy Azure Cosmos DB-adatbázis rendszeres biztonsági másolatából történő visszaállítást vagy egy törölt erőforrás helyreállítását csak Azure-támogatás mérnökök végezhetik el egy támogatási eseten keresztül. Ez a függőség befolyásolhatja az alkalmazás állásidejét. Állapot nélküli erőforrások esetén azt javasoljuk, hogy ahelyett, hogy megvárná, hogy a támogatási mérnökök megpróbálják helyreállítani a törölt erőforrásokat, javasoljuk, hogy telepítse újra az üzembe helyezést.

• Szabályzatkényszerítés. Azure Policy keretrendszert biztosít a biztonsági és megbízhatósági alapkonfigurációk kikényszerítéséhez és naplózásához, hogy biztosítsa a kritikus fontosságú alkalmazások közös mérnöki feltételeinek való megfelelést. Pontosabban az Azure Policy az Azure Resource Manager vezérlősíkjának kulcsfontosságú részét képezi, kiegészítve az RBAC-t az engedélyezett felhasználók által végrehajtható műveletek korlátozásával. A Azure Policy a platformszolgáltatások alapvető biztonsági és megbízhatósági konvencióit érvényesítheti.

• Erőforrások módosítása és törlése. Zárolhatja az Azure-erőforrásokat, hogy megakadályozza azok módosítását vagy törlését. A zárolások azonban felügyeleti többletterhelést okoznak az üzembehelyezési folyamatokban. A legtöbb erőforrás esetében az erőforrás-zárolások helyett szigorú korlátozásokkal rendelkező, robusztus RBAC-folyamatot javasoljuk.

Tervezési javaslatok

• Feladatátvételi eljárások automatizálása. Aktív/aktív modell esetén használjon állapotmodellt és automatizált skálázási műveleteket annak biztosítására, hogy nincs szükség feladatátvételi beavatkozásra. Aktív/passzív modell esetén győződjön meg arról, hogy a feladatátvételi eljárások automatizáltak vagy legalábbis kodifikáltak a folyamatokban.

• Rangsorolja az Azure-natív automatikus skálázás használatát az azt támogató szolgáltatásokhoz. A natív automatikus skálázást nem támogató szolgáltatások esetében használja az automatizált üzemeltetési folyamatokat a szolgáltatások skálázásához. Skálázási egységek használata több szolgáltatással a méretezhetőség eléréséhez.

• Használjon natív platformbeli képességeket a biztonsági mentéshez és visszaállításhoz, biztosítva, hogy azok igazodjanak az RTO/RPO és az adatmegőrzési követelményekhez. Szükség szerint definiáljon egy stratégiát a biztonsági másolatok hosszú távú megőrzéséhez.

• Használjon beépített képességeket az SSL-tanúsítványkezeléshez és -megújításhoz, például az Azure Front Door által biztosítottakhoz.

• Külső csapatok számára hozzon létre egy helyreállítási folyamatot a segítségre szoruló erőforrásokhoz. Ha például az adatplatformot helytelenül módosították vagy törölték, a helyreállítási módszereket jól meg kell érteni, és helyreállítási folyamatnak kell lennie. Hasonlóképpen, hozzon létre eljárásokat a leszerelt tárolólemezképek kezelésére a beállításjegyzékben.

• A standard üzletmenet-folytonossági előkészületek részeként előzetesen gyakorolja a helyreállítási műveleteket nem éles erőforrásokon és adatokon.

• Kritikus riasztások azonosítása és cél célközönségek és rendszerek meghatározása. Világos csatornák definiálása a megfelelő érdekelt felek eléréséhez. Csak végrehajtható riasztásokat küldhet, hogy elkerülje a fehér zajt, és megakadályozza, hogy az operatív érdekelt felek figyelmen kívül hagyják a riasztásokat és a fontos információkat. Folyamatos fejlesztés megvalósítása a riasztások optimalizálásához és a megfigyelt fehér zajok eltávolításához.

• A szabályzatalapú irányítás és a Azure Policy alkalmazásával biztosíthatja az üzemeltetési képességek megfelelő használatát és a megbízható konfigurációs alapkonfigurációt az összes alkalmazásszolgáltatásban.

• Kerülje az erőforrás-zárolások használatát a rövid élettartamú regionális erőforrásokon. Ehelyett támaszkodjon az RBAC- és CI-/CD-folyamatok megfelelő használatára az operatív frissítések szabályozásához. Erőforrás-zárolások alkalmazásával megakadályozhatja a hosszú élettartamú globális erőforrások törlését.

Frissítéskezelés

A kritikus fontosságú kialakítás határozottan támogatja a rövid élettartamú állapot nélküli alkalmazás-erőforrások elvét. Ha ezt az elvet alkalmazza, általában egy új üzembe helyezési és szabványos kézbesítési folyamattal végezhet frissítést.

Kialakítási szempontok

• Igazodás az Azure ütemterveihez. A számítási feladatokat az Azure ütemterveivel igazíthatja, így a platformerőforrások és a futtatókörnyezet függőségei rendszeresen frissülnek.

• Frissítések automatikus észlelése. Folyamatokat állíthat be a frissítések figyelésére és automatikus észlelésére. Használjon olyan eszközöket, mint a GitHub Dependabot.

• Tesztelés és ellenőrzés. A csomagok, összetevők és függőségek új verzióinak tesztelése és ellenőrzése éles környezetben a kiadások előtt. Az új verziók kompatibilitástörő változásokat tartalmazhatnak.

• Futtatókörnyezeti függőségek. Kezelje úgy a futtatókörnyezeti függőségeket, mint az alkalmazás bármely más módosítását. A régebbi verziók biztonsági réseket eredményezhetnek, és negatív hatással lehetnek a teljesítményre. Monitorozza az alkalmazás futtatókörnyezetét, és tartsa naprakészen.

• Komponens higiénia és takarítás. A nem használt erőforrások leszerelése vagy eltávolítása. Figyelheti például a tárolóregisztrációs adatbázisokat, és törölheti a nem használt régi rendszerképverziókat.

Tervezési javaslatok

• Monitorozza ezeket az erőforrásokat, és tartsa naprakészen őket:

  • Az alkalmazásüzemeltési platform. Például rendszeresen frissítenie kell a Kubernetes-verziót Azure Kubernetes Service (AKS) rendszerben, különösen azért, mert a régebbi verziók támogatása nem tartható fenn. Frissítenie kell a Kubernetesen futó összetevőket is, például a tanúsítványkezelőt és az Azure Key Vault CSI-t, és össze kell hangolnia őket az AKS Kubernetes-verziójával.
  • Külső kódtárak és SDK-k (.NET, Java, Python).
  • Terraform-szolgáltatók.

• Az összetevők frissítéséhez kerülje a manuális működési módosításokat. A manuális módosításokat csak vészhelyzetekben érdemes megfontolni. Győződjön meg arról, hogy rendelkezik a manuális módosítások forrásadattárba való újraillesztő folyamatával az eltérés és a probléma ismétlődésének elkerülése érdekében.

• Hozzon létre egy automatizált eljárást a lemezképek régi verzióinak eltávolítására Azure Container Registry.

Titkos kódok kezelése

A kulcs, a titkos kód és a tanúsítvány lejárata gyakori oka az alkalmazáskimaradásnak. A kritikus fontosságú alkalmazások titkos kulcskezelésének biztosítania kell a szükséges biztonságot, és megfelelő rendelkezésre állási szintet kell biztosítania a maximális megbízhatósági követelményeknek megfelelően. A kulcsok, titkos kódok és tanúsítványok rotálását rendszeresen végre kell hajtania egy felügyelt szolgáltatás használatával vagy a frissítéskezelés részeként, és folyamatokat kell alkalmaznia a kód- és konfigurációmódosításokhoz.

Számos Azure-szolgáltatás támogatja a Microsoft Entra hitelesítést ahelyett, hogy kapcsolati sztringekre / kulcsokra támaszkodik. A Microsoft Entra id használata jelentősen csökkenti a működési többletterhelést. Ha titkos kódkezelési megoldást használ, annak integrálnia kell más szolgáltatásokkal, támogatnia kell a zónaszintű és regionális redundanciát, és integrációt kell biztosítania Microsoft Entra azonosítóval a hitelesítéshez és engedélyezéshez. Key Vault ezeket a funkciókat biztosítja.

Kialakítási szempontok

A titkos kódok kezelésének három gyakori megközelítése van. Minden módszer beolvassa a titkos kulcsokat a titkos kódtárból, és egy másik időpontban beszúrja őket az alkalmazásba.

• Üzembehelyezési idő lekérése. Ennek a megközelítésnek az az előnye, hogy a titkos kódkezelési megoldásnak csak az üzembe helyezéskor kell rendelkezésre állnia, mert ezek után nincsenek közvetlen függőségek. Ilyen például a titkos kulcsok környezeti változóként való injektálása Egy Kubernetes-környezetbe vagy egy Kubernetes-titkos kódba.

  Csak az üzembehelyezési szolgáltatásnévnek kell tudnia hozzáférni a titkos kódokhoz, ami leegyszerűsíti az RBAC-engedélyeket a titkos kódkezelő rendszerben.

  Ennek a megközelítésnek azonban vannak hátrányai. Az RBAC összetettségét mutatja be a DevOps-eszközökben a szolgáltatásnév-hozzáférés szabályozása és az alkalmazás számára a lekért titkos kódok védelme tekintetében. Emellett a titkos kódkezelési megoldás biztonsági előnyei nem érvényesülnek, mivel ez a megközelítés csak az alkalmazásplatform hozzáférés-vezérlésére támaszkodik.

  A titkos kódok frissítésének vagy rotálásának megvalósításához teljes újratelepítést kell végrehajtania.

• Alkalmazásindítási lekérés. Ebben a megközelítésben a rendszer lekéri és beszúrja a titkos kódokat az alkalmazás indításakor. Ennek az az előnye, hogy könnyedén frissítheti vagy elforgathatja a titkos kulcsokat. Nem kell titkos kulcsokat tárolnia az alkalmazásplatformon. A legújabb érték lekéréséhez újra kell indítani az alkalmazást.

  A gyakori tárolási lehetőségek közé tartozik az Azure Key Vault Provider for Secrets Store CSI Driver és az akv2k8s. Egy natív Azure-megoldás, Key Vault hivatkozott alkalmazásbeállítások is elérhetők.

  Ennek a megközelítésnek a hátránya, hogy futtatókörnyezeti függőséget hoz létre a titkos kódkezelési megoldástól. Ha a titkos kódkezelési megoldás szolgáltatáskimaradást tapasztal, a már futó alkalmazás-összetevők továbbra is kiszolgálhatják a kéréseket. Minden újraindítási vagy vertikális felskálázási művelet valószínűleg hibához vezetne.

• Futtatókörnyezet lekérése. A titkos kulcsok futásidőben történő lekérése az alkalmazáson belül a legbiztonságosabb módszer, mivel még az alkalmazásplatformnak sincs hozzáférése a titkos kódokhoz. Az alkalmazásnak hitelesítenie kell magát a titkos kódkezelő rendszerben.

  Ehhez a megközelítéshez azonban az alkalmazásösszetevőknek közvetlen függőségre és a titkos kódkezelő rendszerhez való csatlakozásra van szükségük. Ez megnehezíti az összetevők egyenkénti tesztelését, és általában szükségessé teszi egy SDK használatát.

Tervezési javaslatok

• Ha lehetséges, a kapcsolati sztringek vagy kulcsok helyett Microsoft Entra-hitelesítéssel csatlakozhat a szolgáltatásokhoz. Használja ezt a hitelesítési módszert az Azure által felügyelt identitásokkal együtt, hogy ne kelljen titkos kódokat tárolnia az alkalmazásplatformon.

• Használja ki az Key Vault lejárati beállítását, és konfigurálja a közelgő lejáratokra vonatkozó riasztásokat. A standard kiadási folyamattal végezze el az összes kulcs-, titkos kód- és tanúsítványfrissítést.

• Helyezzen üzembe Key Vault példányokat egy regionális bélyeg részeként, hogy mérsékelje az egyetlen üzembehelyezési bélyeg sikertelenségének lehetséges hatását. Használjon egy külön példányt a globális erőforrásokhoz. Az erőforrásokkal kapcsolatos információkért tekintse meg a kritikus fontosságú számítási feladatok jellemző architektúramintáját .

• A szolgáltatásnév hitelesítő adatainak vagy API-kulcsainak kezelésének elkerülése érdekében a szolgáltatásnevek helyett használjon felügyelt identitásokat a Key Vault eléréséhez, amikor csak lehetséges.

• Implementáljon kódolási mintákat annak érdekében, hogy a titkos kulcsok újra lekérhetők legyenek, ha futásidőben engedélyezési hiba történik.

• Alkalmazzon egy teljesen automatizált kulcsrotálási folyamatot, amely rendszeres időközönként fut a megoldáson belül.

• Az Azure Key Vault hamarosan esedékes lejárati értesítésével riasztásokat kaphat a közelgő lejáratokról.

IaaS-specifikus szempontok virtuális gépek használatakor

Ha IaaS virtuális gépeket kell használnia, a jelen dokumentumban korábban ismertetett eljárások és eljárások némelyike eltérhet. A virtuális gépek használata nagyobb rugalmasságot biztosít a konfigurációs lehetőségek, az operációs rendszerek, az illesztőprogram-hozzáférés, az alacsony szintű operációsrendszer-hozzáférés és a telepíthető szoftverek típusai terén. A hátrányok a megnövekedett üzemeltetési költségek és a felhőszolgáltató által a PaaS-szolgáltatások használatakor általában elvégzett feladatokért való felelősség.

Kialakítási szempontok

• Az egyes virtuális gépek nem biztosítanak magas rendelkezésre állást, zónaredundanciát vagy georedundanciát.
• Az egyes virtuális gépek nem frissülnek automatikusan az üzembe helyezésük után. Például a Windows Server 2019-en üzembe helyezett SQL Server 2019 nem frissül automatikusan újabb kiadásra.
• A virtuális gépen futó szolgáltatások speciális kezelést és további eszközöket igényelnek, ha az infrastruktúrán keresztül, kódként szeretné üzembe helyezni és konfigurálni őket.
• Az Azure rendszeresen frissíti a platformját. Ezekhez a frissítésekhez szükség lehet a virtuális gépek újraindítására. az újraindítást igénylő Frissítések általában előre bejelentik. Lásd: Virtuális gépek karbantartása az Azure-ban és Tervezett karbantartási értesítések kezelése.

Tervezési javaslatok

• Kerülje a manuális műveleteket a virtuális gépeken, és implementáljon megfelelő folyamatokat a módosítások üzembe helyezéséhez és bevezetéséhez.

  • Automatizálhatja az Azure-erőforrások kiépítését olyan infrastruktúra-kódként nyújtott megoldások használatával, mint az Azure Resource Manager (ARM)-sablonok, a Bicep, a Terraform vagy más megoldások.

• Győződjön meg arról, hogy a virtuális gépek üzembe helyezéséhez, a frissítésekhez, a biztonsági mentéshez és a helyreállításhoz szükséges üzemeltetési folyamatok működnek és megfelelően vannak tesztelve. A rugalmasság teszteléséhez szúrjon be hibákat az alkalmazásba, jegyezze fel a hibákat, és mérsékelje ezeket a hibákat.

• Győződjön meg arról, hogy vannak olyan stratégiák, amelyek visszaállítják az utolsó ismert kifogástalan állapotot, ha egy újabb verzió nem működik megfelelően.

• Hozzon létre gyakori biztonsági mentéseket az állapotalapú számítási feladatokhoz, győződjön meg arról, hogy a biztonsági mentési feladatok hatékonyan működnek, és riasztásokat implementál a sikertelen biztonsági mentési folyamatokhoz.

• Virtuális gépek monitorozása és hibák észlelése. A monitorozáshoz szükséges nyers adatok számos forrásból származhatnak. Elemezze a problémák okait.

• Győződjön meg arról, hogy az ütemezett biztonsági mentések a várt módon futnak, és hogy szükség esetén létrejönnek az időszakos biztonsági másolatok. A Biztonsági mentési központ segítségével elemzéseket kaphat.

• A virtuális gépek helyett a Virtual Machine Scale Sets használatának rangsorolása olyan képességek engedélyezésére, mint a skálázás, az automatikus skálázás és a zónaredundancia.

• A karbantartandó egyéni rendszerképek helyett rangsorolja a Azure Marketplace szabványos rendszerképeinek használatát.

• Az Azure VM Image Builder vagy más eszközök használatával igény szerint automatizálhatja a testreszabott rendszerképek buildelési és karbantartási folyamatait.

Ezen konkrét ajánlásokon túl alkalmazza az ajánlott eljárásokat a kritikus fontosságú alkalmazási forgatókönyvekre vonatkozó üzemeltetési eljárásokra, adott esetben.

Következő lépés

Tekintse át a kritikus fontosságú alkalmazásforgatókönyvek architektúramintáját:

Architektúraminta