Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
Ez a cikk azt ismerteti, hogy a felhőplatform-csapatok hogyan implementálhatnak védőkorlátokat az azure-beli célzónák alkalmazáskörnyezeteinek kezeléséhez. Azt is ismerteti, hogyan igazíthatók a különböző alkalmazásfejlesztési környezetek a keretrendszerükhöz. A megfelelő környezet létrehozásához kulcsfontosságú szempont az előfizetések megfelelő felügyeleti csoportokba helyezése.
Az alap megteremtése
Az alkalmazás kezdőzónáit három fő módon kezelheti. Válassza ki az igényeinek leginkább megfelelő felügyeleti megközelítést számítási feladatonként:
- Központi csapat megközelítése
- Alkalmazáscsoport megközelítése
- Megosztott csapat megközelítése
| Alkalmazás kezdőzónájának kezelési megközelítése | Leírás |
|---|---|
| Központi csapatkezelés | Egy központi informatikai csapat teljes mértékben működteti a célzónát. A csapat vezérlőket és platformeszközöket alkalmaz a platformra és az alkalmazás kezdőzónáira. |
| Alkalmazáscsoport-kezelés | A platformfelügyeleti csapat a teljes alkalmazás-kezdőzónát egy alkalmazáscsapatnak delegálja. Az alkalmazás csapata felügyeli és támogatja a környezetet. A felügyeleti csoport szabályzatai biztosítják, hogy a platformcsapat továbbra is szabályozza az alkalmazás kezdőzónáját. Az előfizetés hatókörében más szabályzatokat is hozzáadhat, és alternatív eszközök használatával üzembe helyezheti, biztonságossá teheti vagy figyelheti az alkalmazás kezdőzónáit. |
| Megosztott felügyelet | Az olyan technológiai platformokkal, mint az AKS vagy az AVS, egy központi informatikai csapat kezeli a mögöttes szolgáltatást. Az alkalmazáscsapatok felelősek a technológiai platformokon futó alkalmazásokért. Ehhez a modellhez különböző vezérlőket vagy hozzáférési engedélyeket kell használnia. Ezek a vezérlők és engedélyek eltérnek azoktól, amelyeket az alkalmazás kezdőzónáinak központi kezelésére használ. |
Tip
Az alkalmazás kezdőzónáinak különböző típusaival kapcsolatos további útmutatásért tekintse meg a gyakori előfizetés-automatizációs terméksorok létrehozását ismertető témakört.
A fejlesztői csapatoknak szükségük van a gyors iterálási képességre, a felhőszabályozási és platformcsapatoknak pedig nagy léptékben kell kezelni a szervezeti kockázatokat, a megfelelőséget és a biztonságot. Az alkalmazáskörnyezetek megfelelően kezelhetők úgy, hogy két kulcsfontosságú Azure-beli célzóna-tervezési alapelvre összpontosítanak: a szabályzatalapú szabályozásra és az előfizetések demokratizálására. Ezek az alapelvek alapvető védőkorlátokat biztosítanak, és ismertetik, hogyan delegálhat vezérlőket az alkalmazáscsapatoknak. Az alkalmazáscsapatok az Azure Well-Architected Framework útmutatóját használják a számítási feladatok megtervezéséhez. Üzembe helyezik és felügyelik a saját célzóna-erőforrásaikat, és a platformcsapat Azure-szabályzatok hozzárendelésével vezérli az erőforrásokat.
Fontos, hogy tesztkörnyezeti erőforrásokat biztosítson a félig szabályozott erőforrásokhoz, hogy az alkalmazáscsapatok kísérletezhessenek a technológiákkal és képességekkel.
Ha az alkalmazástulajdonosok előfizetés-automatákat vagy más előfizetés-létrehozási folyamatokat használnak, tudniuk kell, hogyan kérhetnek előfizetéseket több fejlesztési környezethez.
Ez a cikk az Azure-beli célzónát ismerteti, beleértve a felügyeleti csoportokat, szabályzatokat és megosztott platformarchitektúrát, valamint a számítási feladatot vagy az alkalmazás célzónát.
Megjegyzés:
A cikkben szereplő útmutatás csak a számítási feladatokra vagy az alkalmazás kezdőzónáira vonatkozik. Az Azure-beli célzónaplatform tesztelésével és a környezet elkülönítésével kapcsolatban lásd az Azure-beli célzónák tesztelési megközelítését, amely a kanári megközelítést ismerteti.
A gyakorlatban bármilyen számú és típusú fázisos környezetet használhat. Ez a cikk a következő szakaszos környezetekre hivatkozik.
| Környezet | Leírás | Felügyeleti csoport |
|---|---|---|
| tesztkörnyezet | Az a környezet, amelyet a prototípusok gyors innovációjára használnak, de nem a gyártásra szánt konfigurációkhoz. | Tesztkörnyezet felügyeleti csoport |
| Fejlődés | A potenciális kiadási jelöltek létrehozásához használt környezet | Archetípus-felügyeleti csoport, például corp vagy online |
| Tesztelés | A teszteléshez használt környezet, beleértve az egységtesztelést, a felhasználói elfogadási tesztelést és a minőségbiztosítási tesztelést | Archetípus-felügyeleti csoport, például corp vagy online |
| Éles környezet | Az a környezet, amely az ügyfeleknek történő értékszállításhoz használatos | Archetípus-felügyeleti csoport, például corp vagy online |
További információkért tekintse meg az alkalmazási munkaterhelések fejlesztési, tesztelési és éles környezeteinek kezeléséről, valamint az Azure-beli előfizetések számáról szóló videókat.
Környezetek, előfizetések és felügyeleti csoportok
Ennek a szakasznak az előfeltételeként tekintse meg az erőforrás-szervezet tervezési területét.
Az Azure-beli kezdőzóna-eljárások bevezetésekor megfelelően kell rendszereznie az előfizetéseket. Ideális esetben minden alkalmazáskörnyezetnek saját előfizetéssel kell rendelkeznie. Ez a módszer olyan biztonsági és szabályzatvezérlőket biztosít, amelyek elkülönítik a környezeteket. Lehetséges problémákat tartalmaz egy adott környezetre.
A különálló előfizetések az archetípus szintjén azonos szabályzatokkal rendelkeznek. Szükség esetén az alkalmazástulajdonosok előfizetés-specifikus szabályzatokat rendelhetnek hozzá az alkalmazás- és környezetspecifikus viselkedés kényszerítéséhez.
Egyes alkalmazásarchitektúrák megkövetelik, hogy a szolgáltatások meg legyenek osztva a környezetek között. Ha ez a helyzet, több környezethez is használhat egyetlen előfizetést. Javasoljuk, hogy a számítási feladatok tulajdonosai a felhőplatform-csapatokkal együttműködve határozzák meg, hogy szükség van-e egyetlen előfizetésre több környezethez.
Használjon egyetlen előfizetést több alkalmazáskörnyezethez, ha:
A környezetek nem különíthetők el a saját előfizetéseikben.
A környezetekben ugyanazok a csapatok vannak hozzárendelve funkcionális szerepkörökhöz, például hálózati operátorokhoz.
A környezetek ugyanazokat a szabályzatokat használhatják.
Ha egy alkalmazás vagy szolgáltatás számítási feladatának egyetlen előfizetésben kell lennie, és módosítania kell az egyes környezetekre vonatkozó szabályzatokat, a következőket teheti:
Hozzon létre egy új archetípushoz igazított felügyeleti csoportot a kezdőzónák felügyeleti csoportja alatt. További információ: A felügyeleti csoport hierarchiája ebben a cikkben.
Fejlesztési tevékenységekhez használjon tesztkörnyezet-előfizetéseket. A homokozók kevésbé korlátozó házirendkészlettel rendelkeznek.
A felügyeleti csoport szintjén helyett az előfizetés szintjén alkalmazott szabályzatokat használhatja. A szabályzatdefiníciókban címkéket adhat hozzá, amelyek segítenek a szabályzatok szűrésében és a megfelelő környezetben való alkalmazásában. A szabályzatokat hozzárendelheti vagy kizárhatja adott erőforráscsoportokból.
Az előfizetés-létrehozási folyamat során szabályzatokat rendelhet hozzá az előfizetés kiosztása részeként.
A költségek szabályozásához implementálandó szabályzatok esetében szükség esetén alkalmazza a szabályzatdefiníciót előfizetési szinten. Vagy a célzóna tulajdonosát is felelőssé teheti a költségekért, ami valódi autonómiát biztosít. További információ: Platformautomatizálás és DevOps.
Figyelmeztetés
A felügyeleti csoport szintjén a szabályzatokkal és vezérlőkkel ellentétben az előfizetés-alapú szabályzatokat és címkéket az előfizetéshez emelt szintű engedélyekkel rendelkező személyek módosíthatják. A megfelelő szerepkörökkel rendelkező rendszergazdák megkerülhetik ezeket a vezérlőket a szabályzatok kizárásával, a szabályzatok módosításával vagy az erőforrások címkéinek módosításával.
Ennek eredményeképpen nem szabad címkéket alkalmazni a biztonságközpontú szabályzatok definícióiban. Emellett az alábbi műveletekhez ne rendeljen hozzá mindig aktív engedélyeket:
Microsoft.Authorization/policyAssignments/*Microsoft.Authorization/policyDefinitions/*Microsoft.Authorization/policyExemptions/*Microsoft.Authorization/policySetDefinitions/*
Ezeket a műveleteket a Privileged Identity Management (PIM) használatával szabályozhatja.
Felügyeleti csoport hierarchiája
Kerülje a bonyolult felügyeleti csoportok hierarchiáját. Gyakori módosítást, nem hatékony skálázást és értékhiányt igényelhetnek. A lehetséges problémák elkerülése érdekében az Azure leszállási zóna kezelési csoportjai a számítási feladatok archetípusaihoz igazodnak. További információ: Felügyeleti csoport és előfizetés-szervezet.
Az archetípus-igazítás azt jelenti, hogy a felügyeleti csoportok csak meghatározott számítási feladatok archetípusaihoz jönnek létre. A fogalmi architektúrában például a kezdőzónák felügyeleti csoportja corp és online gyermekfelügyeleti csoportokkal rendelkezik. Ezek a gyermekfelügyeleti csoportok összhangban vannak az általuk használt számítási feladatok különböző archetípus-mintáival. A gyermekfelügyeleti csoportok a hibrid kapcsolatra (VPN/Azure ExpressRoute) vonatkozó követelményekre összpontosítanak, például csak belső és nyilvános elérésű alkalmazásokra és szolgáltatásokra.
A tesztkörnyezetek kivételével a különböző alkalmazáskörnyezeteknek ugyanazt az archetípust kell használniuk az üzembe helyezéshez. Még akkor is, ha a környezetek több előfizetésre vannak osztva, a felügyeleti csoport archetípusa és a követelmények alapján ugyanabban a felügyeleti csoportban (corp vagy online) vannak tárolva.
A tesztkörnyezet-előfizetéseket strukturálatlan fejlesztéshez, például személyes tesztkörnyezetekhez vagy olyan számítási feladatokhoz használhatja, amelyek nem rendelkeznek archetípussal. Egy alkalmazás- vagy szolgáltatásprofil-csapat tesztkörnyezet-felügyeleti csoportot használ a különböző Azure-szolgáltatások teszteléséhez, hogy megállapítsa, mi felel meg a legjobban a követelményeknek. A szolgáltatások kiválasztása után a csapat számára kiépíthetnek egy "landing zone"-t (a kezdőzónák felügyeleti csoport hierarchiájában a munkaterhelés archetípusához igazított felügyeleti csoportban).
A tesztkörnyezetek adott alkalmazásokhoz használhatók, vagy a számítási feladatok csapata használhatja őket kísérletezéshez.
További információkért lásd:
- Felügyeleti csoportok.
- Erőforrás-szervezési tervezési terület.
- Az Azure célzóna architektúrájának testreszabása a követelményeknek megfelelően.
Környezetalapú felügyeleti csoportokkal kapcsolatos kihívások
Az archetípusokon belüli környezetek felügyeleti csoportjai felügyeleti többletterhelést adhatnak hozzá, és minimális értéket biztosíthatnak.
A landolási zónák kezelőcsoportjának univerzális szabályzatokkal kell rendelkeznie, amelyek védőkorlátokat érvényesítenek mind a corp, mind az online gyermekfelügyeleti csoportok számára. A vállalat és az online olyan egyedi szabályzatokkal rendelkezik, amelyek a nyilvános és magánjellegű feladatokkal kapcsolatos vállalati irányelveket érvényesítik.
Számos szervezet külön felügyeleti csoportokat hoz létre a számítási feladatok szoftverfejlesztési életciklusának (SDLC) környezeteihez a környezeti szabályzatok és vezérlők hozzárendeléséhez. A gyakorlatban ez a módszer több kihívást jelent a számítási feladatokat végző csapatok számára, mint amennyit megold. Az SDLC-környezeteknek nem szabad eltérő szabályzatokkal rendelkezniük, ezért nem javasoljuk külön felügyeleti csoportok használatát.
Az alkalmazástulajdonosok módosíthatják a számítási feladatok topológiáját vagy erőforrás-konfigurációját, hogy igazodjanak az előléptetett több SDLC-környezet szabályzataihoz. Ez a módszer növeli a kockázatot. Az egyes környezetekre jellemző szabályok rossz fejlesztési élményt eredményezhetnek a fejlesztői és minőségbiztosítási csapatok számára. Problémák akkor is felmerülhetnek, ha egy alkalmazás egy környezetben működő védőkorlát-szabályzatokkal rendelkezik, és az alkalmazás az előléptetési ciklus későbbi szakaszában egy másik szabályzatkészletnek lesz kitéve. Előfordulhat, hogy módosítania kell egy alkalmazást, ha a vezérlők megváltoznak.
A további munka elkerülése érdekében hozzon létre egységes szabályzatokat a kód előléptetése során SDLC-környezetekben. Ne hozzon létre házirendeket az egyes környezetekhez, hanem konzisztens készletet biztosítson az összes fejlesztési környezethez, kivéve a tesztkörnyezeteket.
Tegyük fel például, hogy egy szervezet olyan szabályzatot határoz meg, amely megköveteli, hogy a tárfiókok meghatározott tűzfalszabályokkal legyenek konfigurálva, hogy megakadályozzák a nyilvános hálózatokból érkező bejövő forgalmat. Ehelyett a tárfiókok privát végpontokat használnak az Azure-beli célzóna-hálózatokon belül a kommunikációhoz. Ha a fejlesztői környezet nem rendelkezik ilyen szabályzattal, a számítási feladat tesztelése nem találja a nyilvános hozzáférést lehetővé tevő tárfiók helytelen konfigurációját. A teszttelepítések a fejlesztési környezetben működnek, és folyamatosan fejlesztésre kerülnek. Ha a megoldást előléptetik egy másik környezetbe, ahol van tárfiók-szabályzat, az üzembe helyezés az érvényben lévő szabályzat miatt meghiúsul.
Ennek eredményeképpen az alkalmazásfejlesztési csapatnak át kell végeznie az üzembe helyezést és az architektúrát, miután már jelentős erőfeszítéseket tett. Ez a példa bemutatja, hogy a különböző környezetekben lévő különböző szabályzatok hogyan okozhatnak problémákat.
Megjegyzés:
Az alábbi egyenlet bemutatja, hogy miért nem skálázható jól egy külön felügyeleti csoport az egyes környezetekhez vagy számítási feladatokhoz: N számítási feladatok x Z felügyeleti csoportok = összes felügyeleti csoport.
Ha egy szervezet 30 olyan számítási feladattal rendelkezik, amelyekhez egy felügyeleti csoportra és egy gyermekfelügyeleti csoportra van szükség a fejlesztési, tesztelési és éles környezetekhez, a szervezet a következőkkel marad:
N = a számítási feladatok/alkalmazások száma = 30
Z = a számítási feladatok és környezetek felügyeleti csoportjainak száma (1 a számítási feladathoz + 3 a környezetekhez) = 4
N (30) x Z (4) = 120 teljes felügyeleti csoport
Előfordulhat, hogy az alkalmazástulajdonosoknak másként kell alkalmazniuk a szabályzatokat több környezetre. Előfordulhat például, hogy az alkalmazástulajdonosok biztonsági mentési konfigurációkat igényelnek az éles környezetekhez, más környezetekhez azonban nem.
Egyes szabályzatok naplózási szabályzatként engedélyezhetők a felügyeleti csoport szintjén. Az alkalmazáscsapatok határozzák meg a vezérlő implementálását. Ez a módszer nem akadályozza meg az üzembe helyezéseket, de tudatosságot teremt, és lehetővé teszi az alkalmazáscsapatok számára egyedi igényeik kezelését. Ezután létrehozhatnak alszintű szabályzatokat, vagy beépíthetik ezeket a követelményeket az infrastruktúrájukba kód(IaC) üzembehelyezési modulokként.
Ebben a megosztott felelősségi modellben a platformcsapat ellenőrzi a gyakorlatokat, és az alkalmazás csapata kezeli a megvalósítást. Ez a modell javíthatja az üzembe helyezések agilitását.
A platformüzemeltetőknek minden alkalmazás- vagy szolgáltatásterhelési csapattal (kezdőzóna-tulajdonosokkal) együtt kell működniük a követelmények megértéséhez. A platformüzemeltetők az alkalmazáskövetelmények és csomagok alapján biztosíthatnak előfizetéseket. A platformüzemeltetők dönthetnek úgy is, hogy terméksorokat jelölnek ki a különböző típusú számítási feladatokhoz, hogy előfizetés-létrehozási folyamatokat és eszközöket építhessenek ki az alkalmazás- vagy szolgáltatásterhelési csapatok általános követelményei alapján.
Forgatókönyv: Virtuálisgép-alapú számítási feladatok
Az Azure-beli kezdőzónák korai számítási feladatai gyakran Azure-beli virtuális gépekből állnak. Ezeket a számítási feladatokat üzembe helyezheti az Azure-ban, vagy migrálhatja őket meglévő adatközpontokból.
Ahelyett, hogy virtuális gépeket helyez üzembe több környezetben egyetlen előfizetésben, a következőket teheti:
Hozzon létre előfizetéseket az egyes alkalmazáskörnyezetekhez, és helyezze őket ugyanabban az archetípus-felügyeleti csoportban.
Helyezzen üzembe egy virtuális hálózatot minden alkalmazáskörnyezethez a megfelelő előfizetésben. A virtuális hálózat méretét az alkalmazáskörnyezet mérete alapján határozhatja meg.
Helyezze üzembe a virtuális gépeket a megfelelő előfizetésben. A virtuális gépek különböző termékváltozatokat és különböző rendelkezésre állási konfigurációkat használhatnak az egyes környezetekhez, ha szükséges.
A különböző alkalmazáskörnyezeti erőforrásokat különböző hozzáférési vezérlők védik. Ennek eredményeképpen, amikor az alkalmazásfejlesztők üzembehelyezési folyamatokat állítanak be, az egyes folyamatok identitása a környezetre korlátozható. Ez a konfiguráció segít megvédeni a környezeteket a véletlen telepítésektől.
Forgatókönyv: Azure App Service
Az App Service-t használó környezeti előfizetésekkel rendelkező számítási feladatok kihívást jelenthetnek. Az alkalmazásfejlesztők számára az App Service ajánlott eljárása az üzembehelyezési pontok használata a webalkalmazások módosításainak és frissítéseinek kezeléséhez.
Ez a funkció azonban csak az App Service-csomagban lévő alkalmazással használható, amely csak egyetlen előfizetésen belül tud élni. Ha a platformüzemeltetők azt kérik, hogy az alkalmazástulajdonosok külön előfizetéseket használjanak fejlesztési, tesztelési és éles környezetekhez, az alkalmazás üzembe helyezési életciklusa nehezebb lehet.
Ebben a példában a legjobb megoldás egyetlen előfizetés az alkalmazás- vagy szolgáltatásterheléshez. Az alkalmazástulajdonosok az azure-beli szerepköralapú hozzáférés-vezérlést (RBAC) az erőforráscsoport szintjén használhatják a PIM használatával a nagyobb biztonság érdekében.