Végpontok közötti szabályozás az Azure-ban CI/CD használata esetén

A szervezet irányítási modelljének fejlesztésekor fontos megjegyezni, hogy az Azure Resource Manager csak egy módszer az erőforrások kezelésére. Az Azure DevOps és a folyamatos integráció és folyamatos teljesítés (CI/CD) automatizálás nem szándékos biztonsági háttérrendszer lehet, ha nincs megfelelően biztosítva. Ezeket az erőforrásokat a Resource Managerhez használt szerepköralapú hozzáférés-vezérlési (RBAC) modell tükrözésével kell védeni.

A végpontok közötti irányítás fogalma a szállítói agnosztikus. Az itt ismertetett implementáció az Azure DevOpsot használja, de az alternatív megoldásokról is szó esik.

Lehetséges használati esetek

Ez a referencia-implementáció és demó nyílt forráskódú, és oktatási eszközként szolgál a DevOps újdonságait ismerő szervezetek számára, és egy szabályozási modellt kell létrehoznia az Azure-ban való üzembe helyezéshez. Gondosan olvassa el ezt a forgatókönyvet, hogy megértse az ebben a mintaadattárban használt modell mögötti döntéseket.

Minden szabályozási modellt a szervezet üzleti szabályaihoz kell kötni, amelyek a hozzáférés-vezérlések technikai megvalósításában is tükröződnek. Ez a példamodell egy fiktív vállalatot használ az alábbi gyakori forgatókönyvvel (üzleti követelményekkel):

  • Üzleti tartományokkal és engedélymodellekkel összhangban lévő Microsoft Entra-csoportok
    A szervezet számos vertikális üzleti tartománnyal rendelkezik, mint például a "gyümölcs" és a "zöldség", amelyek nagyrészt egymástól függetlenül működnek. Minden üzleti tartományban két szint vagy jogosultság található, amelyek különböző *-admins vagy *-devs Microsoft Entra-csoportokra vannak leképezve. Ez lehetővé teszi a fejlesztők számára, hogy célzottan konfigurálják az engedélyeket a felhőben.

  • Üzembehelyezési környezetek
    Minden csapat két környezettel rendelkezik:

    • Termelés. Csak a rendszergazdák rendelkeznek emelt szintű jogosultságokkal.
    • Nem éles. Minden fejlesztő emelt szintű jogosultságokkal rendelkezik (a kísérletezés és az innováció ösztönzése érdekében).

  • Automatizálási célok
    Minden alkalmazásnak implementálnia kell az Azure DevOps-t nem csak a folyamatos integráció (CI), hanem a folyamatos üzembe helyezés (CD) érdekében is. Az üzembe helyezéseket például automatikusan aktiválhatja a Git-adattár módosítása.

  • Felhőbeli utazás eddig
    A szervezet egy izolált projektmodellel kezdte, hogy felgyorsítsa a felhőbe vezető utat. Most azonban olyan lehetőségeket keresnek, amelyekkel megtörhetik a silókat, és az "együttműködés" és a "szupermarket" projektek létrehozásával ösztönözhetik az együttműködést.

Ez az egyszerűsített diagram bemutatja, hogy a Git-adattárbeli ágak hogyan képeznek le fejlesztési, előkészítési és éles környezeteket:

A Git-adattár különböző webes környezetekhez leképezett ágainak egyszerűsített diagramja
Töltsön le egy SVG fájlt ebből a diagramról.

Architecture

Ez az ábra bemutatja, hogy a Resource Manager és a CI/CD és a Microsoft Entra ID összekapcsolása a végpontok közötti szabályozási modell kulcsa.

A végpontok közötti szabályozás áttekintése a Microsoft Entra-azonosítóval a középpontban
Töltse le az architektúra SVG-jének letöltését.

Megjegyzés:

A koncepció érthetőbbé tétele érdekében a diagram csak a "veggies" tartományt szemlélteti . A "fruit" tartomány hasonló lenne, és ugyanazokat az elnevezési konvenciókat használná.

Workflow

A számozás azt a sorrendet tükrözi, amelyben a rendszergazdák és a vállalati tervezők gondolkodnak és konfigurálják a felhőbeli erőforrásaikat.

  1. Microsoft Entra-azonosító

    Az Azure DevOpsot a Microsoft Entra ID-val integráljuk, hogy egyetlen identitássík legyen. Ez azt jelenti, hogy egy fejlesztő ugyanazt a Microsoft Entra-fiókot használja az Azure DevOpshoz és a Resource Managerhez is. A felhasználók nem külön-külön vannak hozzáadva. Ehelyett a Microsoft Entra-csoportok rendelik hozzá a tagságot, hogy egyetlen lépésben eltávolíthassuk a fejlesztők hozzáférését az erőforrásokhoz – a Microsoft Entra-csoporttagságuk eltávolításával. Minden tartományhoz a következőt hozjuk létre:

    • Microsoft Entra-csoportok. Tartományonként két csoport (erről a cikk 4. és 5. lépésében olvashat bővebben).
    • Szolgáltatásnevek. Környezetenként egy explicit szolgáltatásnév.

  2. Éles környezet

    Az üzembe helyezés egyszerűsítése érdekében ez a referencia-implementáció egy „resource group”-ot használ az éles környezet ábrázolásához. A gyakorlatban egy másik előfizetést kell használnia.

    A környezethez való emelt szintű hozzáférés csak rendszergazdákra korlátozódik.

  3. fejlesztési környezet

    Az üzembe helyezés egyszerűsítése érdekében ez a referencia-implementáció egy erőforráscsoportot használ a fejlesztési környezet megjelenítéséhez. A gyakorlatban egy másik előfizetést kell használnia.

  4. Szerepkör-hozzárendelések a Resource Managerben

    Bár a Microsoft Entra-csoportnevek egy szerepkört jelölnek, a hozzáférés-vezérlések csak a szerepkör-hozzárendelés konfigurálásához lesznek alkalmazva. Ez szerepet rendel hozzá egy Microsoft Entra-megbízotthoz egy adott hatókörhöz. A fejlesztők például közreműködői szerepkört kapnak az éles környezetben.

    Microsoft Entra-főazonosító Fejlesztői környezet (Resource Manager) Éles környezet (Resource Manager)
    veggies-devs-group Owner Olvasó
    veggies-admins-group Tulajdonos Tulajdonos
    veggies-ci-dev-sp Egyéni szerepkör * –
    veggies-ci-prod-sp – Egyéni szerepkör *

    * Az üzembe helyezés egyszerűsítése érdekében ez a referencia-implementáció hozzárendeli a Owner szerepkört a szolgáltatásnevekhez. Az éles környezetben azonban létre kell hoznia egy egyéni szerepkört, amely megakadályozza, hogy a szolgáltatási főfelhasználó eltávolítsa az Ön által az erőforrásokon elhelyezett felügyeleti zárolásokat. Ez segít megvédeni az erőforrásokat a véletlen sérülésektől, például az adatbázis törlésétől.

    Az egyes szerepkör-hozzárendelések mögötti érvelés megértéséhez tekintse meg a cikk későbbi, megfontolandó szempontok szakaszát .

  5. Biztonsági csoportok hozzárendelései az Azure DevOpsban

    A biztonsági csoportok szerepkörként működnek a Resource Managerben. Használja ki a beépített szerepköröket és az alapértelmezett közreműködői szerepköröket a fejlesztők számára. A rendszergazdák emelt szintű engedélyeket kapnak a Projektadminisztrátor biztonsági csoporthoz, lehetővé téve számukra a biztonsági engedélyek konfigurálását.

    Vegye figyelembe, hogy az Azure DevOps és a Resource Manager különböző engedélymodellekkel rendelkezik:

    Ezért a -admins és -devs csoportok tagságának kölcsönösen kizárónak kell lennie. Ellenkező esetben az érintett személyek a vártnál kevesebb hozzáféréssel rendelkeznének az Azure DevOpsban.

    Csoport neve Erőforrás-kezelő szerepkör Azure DevOps szerepkör
    fruits-all – –
    fruits-devs Közreműködő Közreműködő
    fruits-admins Tulajdonos Projektgazdák
    veggies-all – –
    veggies-devs Közreműködő Közreműködő
    veggies-admins Tulajdonos Projektgazdák
    infra-all – –
    infra-devs Közreműködő Közreműködő
    infra-admins Tulajdonos Projektgazdák

    A korlátozott együttműködés forgatókönyvében, például a gyümölcscsapat meghívja a zöldségcsapatot, hogy egyetlen adattáron működjön együtt, a veggies-all csoportot alkalmaznák.

    Az egyes szerepkör-hozzárendelések mögötti érvelés megértéséhez tekintse meg a cikk későbbi, megfontolandó szempontok szakaszát .

  6. Szolgáltatáskapcsolatok

    Az Azure DevOpsban a szolgáltatáskapcsolat egy általános burkoló a hitelesítő adatok köré. Létrehozunk egy szolgáltatáskapcsolatot, amely tartalmazza a szolgáltatásnév ügyfélazonosítóját és az ügyfél titkos kódját. A projektgazdák szükség esetén konfigurálhatják a védett erőforráshoz való hozzáférést, például ha az üzembe helyezés előtt emberi jóváhagyásra van szükség. Ez a referenciaarchitektúra két minimális védelemmel rendelkezik a szolgáltatáskapcsolaton:

    • A rendszergazdáknak konfigurálnia kell a folyamatengedélyeket annak szabályozásához, hogy mely folyamatok férhetnek hozzá a hitelesítő adatokhoz.
    • A rendszergazdáknak be kell állítaniuk egy ágvezérlés-ellenőrzést, hogy csak a production ágon belül futó csővezetékek használhassák a prod-connection.

  7. Git-adattárak

    Mivel a szolgáltatáskapcsolatok ágvezérlőkön keresztül kapcsolódnak az ágakhoz, kritikus fontosságú a Git-adattárak engedélyeinek konfigurálása és az ágházirendek alkalmazása. A CI-buildek sikeres teljesítése mellett megköveteljük, hogy a pull requesteknek legalább két személy általi jóváhagyása legyen.

Components

Alternatives

A végpontok közötti irányítás fogalma a szállítói agnosztikus. Bár ez a cikk az Azure DevOpsról szól, az Azure DevOps Server helyszíni helyettesítőként is használható. Alternatív megoldásként egy nyílt forráskódú CI-/CD-fejlesztési folyamathoz is használhat különböző technológiákat, például a Jenkins és a GitLab használatával.

Az Azure Repos és a GitHub is olyan platform, amely a nyílt forráskódú Git verziókövetési rendszer használatára készült. Bár a funkciókészletek némileg eltérőek, mindkettő integrálható a CI/CD globális szabályozási modelljeibe. A GitLab egy másik Git-alapú platform, amely robusztus CI/CD-képességeket biztosít.

Ez a forgatókönyv a Terraformot használja az infrastruktúra kód (IaC) eszközként. Az alternatív lehetőségek közé tartozik a Jenkins, az Ansible és a Chef.

Megfontolások

Az Azure-ban a teljes körű szabályozás érdekében fontos megismerni a fejlesztő számítógépétől az éles környezetig vezető út biztonsági és engedélyprofilját. Az alábbi ábra egy alapszintű CI/CD-munkafolyamatot mutat be az Azure DevOpsszal. A piros zárolás ikon azt jelzi, hogy a felhasználónak milyen biztonsági engedélyeket kell konfigurálnia. Ha nem konfigurálja vagy helytelenül konfigurálja az engedélyeket, az sebezhetővé teszi a számítási feladatokat.

Alapszintű CI/CD-munkafolyamatot szemléltető ábra az Azure DevOpsszal
Töltse le a munkafolyamat SVG-jének letöltését.

A számítási feladatok biztonságossá tételéhez biztonsági engedélykonfigurációk és emberi ellenőrzések kombinációját kell használnia a munkafolyamatban. Fontos, hogy minden RBAC-modellnek ki kell terjednie a folyamatokra és a kódra is. Ezek gyakran kiemelt identitásokkal futnak, és ha erre utasítják, megsemmisítik a számítási feladatokat. Ennek megakadályozása érdekében az adattár ágszabályzatait úgy kell konfigurálnia, hogy emberi jóváhagyást igényeljenek, mielőtt elfogadná az automatizálási folyamatokat kiváltó módosításokat.

Üzembe helyezési szakaszok Felelősség Description
Lekéréses kérelmek User A mérnököknek meg kell vizsgálniuk a munkájukat, beleértve magát a folyamatkódot is.
Ágvédelem megosztott Konfigurálja az Azure DevOpst, hogy elutasítsa azokat a módosításokat, amelyek nem felelnek meg bizonyos szabványoknak, például a CI-ellenőrzéseknek és a társértékeléseknek (lekéréses kérelmeken keresztül).
Folyamat kódként User A buildkiszolgáló törli a teljes éles környezetet, ha a folyamatkód erre utasítja. A lekéréses kérelmek és az ágvédelmi szabályok, például az emberi jóváhagyás kombinációjával segíthet megelőzni ezt.
Szolgáltatáskapcsolatok megosztott Az Azure DevOps konfigurálása a hitelesítő adatokhoz való hozzáférés korlátozásához.
Azure-erőforrások megosztott Az RBAC konfigurálása a Resource Managerben.

A szabályozási modell tervezésekor fontos figyelembe venni az alábbi fogalmakat és kérdéseket. Vegye figyelembe a példaszervezet lehetséges használati eseteit .

1. A környezetek védelme ágszabályzatokkal

Mivel a forráskód határozza meg és aktiválja az üzembe helyezéseket, az első védelmi vonal a forráskódkezelő (SCM) adattár védelme. Ez a gyakorlatban a Lekéréses kérelem munkafolyamat és az elágazási szabályzatok együttes használatával érhető el, amelyek a kód elfogadása előtti ellenőrzéseket és követelményeket határozzák meg.

A végpontok közötti szabályozási modell tervezésekor a kiemelt felhasználók (veggies-admins) lesznek felelősek az ágvédelem konfigurálásáért. A telepítések biztonságának biztosítására gyakran használt ágvédelmi ellenőrzések a következők:

  • A CI build sikeres lefutásának megkövetelése. Hasznos az alapkódminőség meghatározásához, például a kódellenőrzéshez, az egységtesztekhez és még a biztonsági ellenőrzésekhez is, például a vírusszkenneléshez és a hitelesítő adatok ellenőrzéséhez.

  • Szakmai felülvizsgálat követelménye Biztosítsa egy másik kolléga ellenőrzésével, hogy a kód a szándékolt módon működik. A folyamatkód módosításakor fokozott óvatosságra van szükség. A CI-buildekkel kombinálva kevésbé unalmassá teheti a társértékeléseket.

Mi történik, ha egy fejlesztő közvetlenül az éles környezetbe próbál leküldni?

Ne feledje, hogy a Git egy elosztott SCM-rendszer. A fejlesztő közvetlenül a helyi production ágra kommitálhat. Ha azonban a Git megfelelően van konfigurálva, az ilyen leküldéseket a Git-kiszolgáló automatikusan elutasítja. Például:

remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "continuous-integration" is expected.
To https://github.com/Azure/devops-governance
 ! [remote rejected] main -> main (protected branch hook declined)
error: failed to push some refs to 'https://github.com/Azure/devops-governance'

Vegye figyelembe, hogy a példában szereplő munkafolyamat a szállítói agnosztikus. A lekéréses kérelmek és az ágvédelmi funkciók több SCM-szolgáltatótól is elérhetők, például az Azure Repostól, a GitHubtól és a GitLabtől.

Miután elfogadta a kódot egy védett ágba, a következő hozzáférési réteget alkalmazza a buildkiszolgáló (például az Azure Pipelines).

2. Milyen hozzáférésre van szükségük a biztonsági tagoknak?

Az Azure-ban a biztonsági szereplő lehet felhasználói szereplő vagy fej nélküli szereplő, például szolgáltatás szereplő vagy felügyelt identitás. Minden környezetben a biztonsági tagoknak a minimális jogosultság elvét kell követnie. Bár a biztonsági tagok bővített hozzáféréssel rendelkezhetnek a tesztkörnyezetekben, az éles Azure-környezeteknek minimálisra kell csökkenteniük az állandó engedélyeket, előnyben részesítve az igény szerinti (JIT) hozzáférést és a Microsoft Entra feltételes hozzáférést. Az Azure RBAC-szerepkör-hozzárendeléseket úgy kell megtervezni a felhasználói fők számára, hogy igazodjanak a legkisebb jogosultsági szintű elvekhez.

Fontos, hogy az Azure RBAC-t külön modellezni az Azure DevOps RBAC-től. A folyamat célja az Azure-hoz való közvetlen hozzáférés minimalizálása. Az olyan különleges esetek kivételével, mint az innováció, a tanulás és a problémamegoldás, az Azure-ral való legtöbb interakciót célalapú és kapus folyamatokon keresztül kell végrehajtani.

Az Azure Pipeline szolgáltatásnevek esetében fontolja meg egy egyéni szerepkör használatát, amely megakadályozza, hogy eltávolítsa az erőforrás-zárolásokat, és más romboló műveleteket hajtson végre a hatókörön kívül.

3. Testreszabott szerepkör létrehozása az éles környezethez való hozzáféréshez használt szolgáltatásfőelemhez

Gyakori hiba a CI/CD build ügynökök tulajdonosi szerepköreinek és engedélyeinek megadása. A közreműködői engedélyek nem elegendőek, ha a folyamatnak identitásszerepkör-hozzárendeléseket vagy más kiemelt műveleteket, például a Key Vault szabályzatkezelését is végre kell hajtania.

A CI/CD Build Agent azonban törölheti a teljes éles környezetet, ha erre utasítják. A visszafordíthatatlan romboló változások elkerülése érdekében létrehozunk egy egyéni szerepkört, amely:

  • A Key Vault hozzáférési szabályzatainak eltávolítása
  • Eltávolítja azokat a felügyeleti zárolásokat , amelyeknek tervezéssel meg kell akadályoznia az erőforrások törlését (a szabályozott iparágakban gyakori követelmény)

Ehhez létrehozunk egy egyéni szerepkört, és eltávolítjuk a Microsoft.Authorization/*/Delete műveleteket.

{
  "Name": "Headless Owner",
  "Description": "Can manage infrastructure.",
  "actions": [
    "*"
  ],
  "notActions": [
    "Microsoft.Authorization/*/Delete"
  ],
  "AssignableScopes": [
    "/subscriptions/{subscriptionId1}",
    "/subscriptions/{subscriptionId2}",
    "/providers/Microsoft.Management/managementGroups/{groupId1}"
  ]
}

Ha ez túl sok engedélyt távolít el az Ön számára, tekintse meg az Azure-erőforrás-szolgáltatói műveletek hivatalos dokumentációjának teljes listáját, és szükség szerint módosítsa a szerepkördefiníciót.

A forgatókönyv üzembe helyezése

Ez a forgatókönyv túlmutat a Resource Manageren. Ezért használjuk a Terraformot, amely lehetővé teszi, hogy a Microsoft Entra ID-ban azonosítókat hozzunk létre, és az Azure DevOps előkészítéséhez egyetlen infrastruktúra mint kódeszközzel dolgozzunk.

A forráskódért és a részletes utasításokért látogasson el az Azure Demo GitHub-adattárának irányítására – a DevOpstól az ARM-hez.

Pricing

Az Azure DevOps költségei a hozzáférést igénylő felhasználók számától függenek, valamint egyéb tényezőktől, például a szükséges egyidejű buildek/kiadások számától és a felhasználók számától. Az Azure Repos és az Azure Pipelines az Azure DevOps szolgáltatás funkciói. További információ: Azure DevOps díjszabási.

A Microsoft Entra ID-ban az ehhez a forgatókönyvhöz szükséges csoporthozzáférés-kezelés típusa a Prémium P1 és a Prémium P2 kiadásban érhető el. Ezeknek a szinteknek a díjszabását felhasználónként számítjuk ki. További információért lásd: Microsoft Entra árképzés.

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerző:

Következő lépések

  • Last updated on