Biztonságos ügynökök, projektek és tárolók

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Az Azure Pipelines biztonságossá tételével kapcsolatban számos egyéb szempontot is szem előtt kell tartani, például a megosztott infrastruktúra, az adattárak, a projektekstb. védelmét.

Ez a cikk egy sorozat része, amely segít az Azure Pipelines biztonsági intézkedéseinek megvalósításában. További információ: Biztonságos Azure Pipelines.

Előfeltételek

Kategória	Követelmények
Azure DevOps	– Javaslatok megvalósítása az Azure DevOps biztonságossá tételében és az Azure Pipelines biztonságossá tételében. - A YAML és az Azure Pipelines alapszintű ismerete. További információért tekintse meg a Első adatfolyam létrehozása című részt.
Engedélyek	– Folyamatengedélyek módosítása: A Projektgazdák csoport tagja. – A szervezeti engedélyek módosítása: A Projektcsoportgazdák csoport tagja.

Megosztott infrastruktúra védelme

Az Azure Pipelines védett erőforrásai a valós infrastruktúra absztrakciói. Kövesse ezeket a javaslatokat a mögöttes infrastruktúra védelméhez.

A Microsoft által üzemeltetett készletek használata

A Microsoft által üzemeltetett készletek elkülönítést és tiszta virtuális gépet biztosítanak egy folyamat minden egyes futtatásához. Ha lehetséges, használja a Microsoft által üzemeltetett készleteket a saját üzemeltetésű készletek helyett.

Ügynökök elkülönítése minden projekthez

Egy ügynök csak egyetlen készlethez társítható. Az ügynökök projektek közötti megosztásához társíthatja a készletet több projekttel. A gyakorlatban több projekt is használhatja ugyanazt az ügynököt egymás után. A költséghatékonyság mellett ez a megközelítés oldalirányú mozgási kockázatokat is okozhat.

Az oldalirányú mozgás mérséklése és a projektek közötti keresztszennyeződés megakadályozása érdekében külön ügynökkészleteket kell fenntartania, amelyek mindegyike egy adott projekthez tartozik.

Alacsony jogosultságú fiókok használata ügynökök futtatásához

Bár előfordulhat, hogy kísértésbe ütközik, az ügynök futtatása egy olyan identitás alatt, amely közvetlen hozzáféréssel rendelkezik az Azure DevOps-erőforrásokhoz, kockázatos lehet. Ez a beállítás elterjedt a Microsoft Entra-azonosítót használó szervezeteknél, de kockázatot jelent. Ha az ügynököt a Microsoft Entra ID által támogatott identitással futtatja, közvetlenül hozzáférhet az Azure DevOps API-khoz anélkül, hogy a feladat hozzáférési jogkivonatára támaszkodna. A nagyobb biztonság érdekében fontolja meg az ügynök futtatását egy nem hátrányos helyi fiókkal, például a Hálózati szolgáltatással.

Fontos

Az Azure DevOpsban létezik egy Project Collection Service-fiókok nevű csoport, amely félrevezető lehet. Az öröklés alapján a Project Collection Szolgáltatásfiókok tagjai szintén a Projektgyűjtemény-rendszergazdák tagjai. Egyes ügyfelek a Microsoft Entra ID által támogatott identitással futtatják a buildügynökeiket, és ezek az identitások a Project Collection szolgáltatásfiókjainak részét képezhetik. Ha azonban a támadók egy folyamatot futtatnak ezen buildügynökök egyikén, akkor az egész Azure DevOps-szervezet felett átvehetik az irányítást.

Vannak olyan példányok, ahol a saját üzemeltetésű ügynökök magas jogosultsági szintű fiókokban működnek. Ezek az ügynökök gyakran használják ezeket a kiemelt fiókokat titkos kódok vagy éles környezetek eléréséhez. Ha azonban a támadók feltört folyamatot hajtanak végre az egyik ilyen buildügynökön, hozzáférhetnek ezekhez a titkos kódokhoz. Ezután a támadók oldalirányban mozoghatnak az ezeken a fiókokon keresztül elérhető más rendszereken.

A rendszerbiztonság javítása érdekében javasoljuk, hogy a legalacsonyabb jogosultságú fiókot használja a saját üzemeltetésű ügynökök futtatásához. Fontolja meg például a számítógépfiók vagy a felügyelt szolgáltatás identitásának használatát. Emellett megbízhatja az Azure Pipelinest a titkos kódokhoz és környezetekhez való hozzáférés kezelésével.

A szolgáltatáskapcsolatok hatókörének minimalizálása

Győződjön meg arról, hogy a szolgáltatáskapcsolatok csak a szükséges erőforrásokhoz férnek hozzá. Amikor lehetséges, fontolja meg a számítási feladatok identitásának összevonását egy szolgáltatásnév helyett az Azure-szolgáltatáskapcsolathoz. A számítási feladatok identitásának összevonása az Open ID Connect (OIDC) iparági szabvány szerinti technológiát használja az Azure és az Azure DevOps közötti hitelesítés megkönnyítésére titkos kódok használata nélkül.

Győződjön meg arról, hogy az Azure-szolgáltatáskapcsolat hatóköre csak a szükséges erőforrások eléréséhez szükséges. Ne adjon széles körű közreműködői jogokat a teljes Azure-előfizetéshez a felhasználóknak.

Amikor új Azure Resource Manager-szolgáltatáskapcsolatot hoz létre, mindig válasszon egy adott erőforráscsoportot. Győződjön meg arról, hogy az erőforráscsoport csak a buildhez szükséges virtuális gépeket vagy erőforrásokat tartalmazza. Hasonlóképpen, a GitHub-alkalmazás konfigurálásakor csak az Azure Pipelines használatával létrehozni kívánt adattárakhoz adjon hozzáférést.

Projektek védelme

Az egyes erőforrásokon túl az Azure DevOps erőforráscsoportjait is figyelembe kell venni. Az erőforrások csapatprojektek szerint rendszerezhetők, és elengedhetetlen annak megértése, hogy a folyamat milyen hozzáféréseket érhet el a projektbeállítások és az elszigetelés alapján.

A folyamat minden feladata kap egy hozzáférési jogkivonatot, amely jogosult a megnyitott erőforrások olvasására. Bizonyos esetekben a folyamatok is frissíthetik ezeket az erőforrásokat. Ez azt jelenti, hogy bár a felhasználói fiók nem rendelkezik közvetlen hozzáféréssel egy adott erőforráshoz, a folyamatban futó szkriptek és feladatok továbbra is elérhetik azt. Emellett az Azure DevOps biztonsági modellje lehetővé teszi ezeknek az erőforrásoknak a elérését a szervezet más projektjeiből. Ha úgy dönt, hogy korlátozza a folyamatok hozzáférését bizonyos erőforrásokhoz, ez a döntés a projekt összes folyamatára vonatkozik – az adott folyamatok nem adhatnak szelektív hozzáférést a megnyitott erőforrásokhoz.

Különálló projektek

A nyílt erőforrások jellegéből adódóan fontolja meg az egyes termékek és csapatok külön projektekben történő kezelését. Ezzel megakadályozhatja, hogy az egyik termék folyamatai véletlenül hozzáférjenek egy másik termék nyitott erőforrásaihoz, így minimalizálva az oldalirányú kitettséget. Ha azonban több csapat vagy termék osztozik egy projekten, az erőforrások részletes elkülönítése nehézkessé válik.

Ha az Azure DevOps-szervezet 2019 augusztusa előtt jött létre, a futtatások továbbra is hozzáférhetnek a szervezet összes projektjének erőforrásaihoz. A szervezet rendszergazdájának át kell tekintenie egy kritikus biztonsági beállítást az Azure Pipelinesban, amely lehetővé teszi a folyamatok projektelkülönítését.

Ezt a beállítást a Szervezeti beállítások>Folyamatok>Beállításai alatt találja, vagy közvetlenül: https://dev.azure.com/Organization_Name/_settings/pipelinessettings.

Adattárak védelme

A verziókövetési adattárakban tárolhatja a forráskódot, a folyamat YAML-fájlját, valamint a szükséges szkripteket és eszközöket. A kód és a folyamat biztonságos módosítása érdekében elengedhetetlen az engedélyek és a fiókszabályzatok alkalmazása. Emellett érdemes lehet folyamatengedélyeket és ellenőrzéseket hozzáadni az adattárakhoz.

Emellett tekintse át az adattárak alapértelmezett hozzáférés-vezérlési beállításait .

Ne feledje, hogy a Git kialakítása azt jelenti, hogy az ágszintű védelem korlátozásokkal rendelkezik. Az adattárhoz leküldéses hozzáféréssel rendelkező felhasználók általában új ágakat hozhatnak létre. Ha nyílt forráskódú GitHub-projektekkel dolgozik, bárki, aki Rendelkezik GitHub-fiókkal, elágaztathatja az adattárat, és felajánlhat hozzájárulásokat. Mivel a folyamatok egy adattárhoz vannak társítva (nem konkrét ágakhoz), elengedhetetlen a kód- és YAML-fájlok potenciálisan nem megbízhatóként való kezelése.

Villa

Amikor nyilvános adattárakkal dolgozik a GitHubon, elengedhetetlen, hogy alaposan átgondolja az elágazások készítésének megközelítését. A szervezeten kívülről származó villák különleges kockázatokat jelentenek. Annak érdekében, hogy megvédhesse termékeit a potenciálisan nem megbízható kódtól, vegye figyelembe az alábbi javaslatokat

Feljegyzés

Ezek a javaslatok elsősorban a GitHub nyilvános adattárainak létrehozására vonatkoznak.

Ne adjon titkos kulcsokat az elágazás-buildekhez

Alapértelmezés szerint a folyamatok villák készítésére vannak konfigurálva, de a titkos kulcsok és a védett erőforrások nem lesznek automatikusan kitéve a folyamatok feladatainak. A biztonság fenntartása érdekében fontos, hogy ne tiltsa le ezt a védelmet.

Feljegyzés

Ha engedélyezi az elágazás-buildeket a titkos kódok eléréséhez, az Azure Pipelines korlátozza az alapértelmezés szerint használt hozzáférési jogkivonatot. Ez a jogkivonat a normál hozzáférési jogkivonathoz képest korlátozott hozzáféréssel rendelkezik a megnyitott erőforrásokhoz. Ha az elágazás-buildekhez ugyanazokat az engedélyeket szeretné biztosítani, mint a normál buildek, engedélyezze, hogy a Fork buildek ugyanolyan engedélyekkel rendelkezzenek, mint a normál buildek beállítása.

Fontolja meg az elágaztatási buildek manuális aktiválását

Kikapcsolhatja az automatikus fork build-eket, és ehelyett a pull request megjegyzéseket használhatja ezeknek a hozzájárulásoknak a manuális építésére. Ezzel a beállítással áttekintheti a kódot, mielőtt elindít egy buildet.

A Microsoft által üzemeltetett ügynökök használata elágazás-buildekhez

Kerülje a buildek futtatását az elágazásokból a saját üzemeltetésű ügynökökön. Ez lehetővé teheti, hogy a külső szervezetek külső kódot hajtsanak végre a vállalati hálózaton belüli gépeken. Amikor csak lehetséges, használja a Microsoft által üzemeltetett ügynököket. A saját üzemeltetésű ügynökök esetében implementálja a hálózatelkülönítést, és gondoskodjon arról, hogy az ügynökök ne őrizzék meg az állapotukat a feladatok között.

Kódmódosítások áttekintése

Mielőtt elágazott lekéréses kérelemen futtatja a folyamatot, alaposan tekintse át a javasolt módosításokat, és győződjön meg arról, hogy kényelmesen futtatja.

A futtatott YAML-folyamat verziója a lekéréses kérelemből származik. Ezért különös figyelmet kell fordítani a YAML-kód és a folyamat futtatásakor futó kód változásaira, például parancssori szkriptekre vagy egységtesztekre.

A GitHub-jogkivonat hatókörének korlátozása

GitHub-elágaztatási lekéréses kérelem létrehozásakor az Azure Pipelines biztosítja, hogy a folyamat ne módosítsa a GitHub-adattár tartalmát. Ez a korlátozás csak akkor érvényes, ha az Azure Pipelines GitHub alkalmazást használja a GitHubkal való integrációhoz. Ha a GitHub-integráció más formáit, például az OAuth alkalmazást használja, a korlátozás nem lesz kényszerítve.

Felhasználói ágak

A szervezet megfelelő engedélyekkel rendelkező felhasználói új, vagy frissített kódot tartalmazó ágakat hozhatnak létre. Ez a kód ugyanazon a folyamaton futhat, mint a védett ágak. Ha az új ágBAN lévő YAML-fájl módosul, akkor a frissített YAML a folyamat futtatásához lesz használva. Bár ez a kialakítás nagy rugalmasságot és önkiszolgálóságot tesz lehetővé, nem minden módosítás biztonságos (akár rosszindulatúan, akár nem).

Ha a folyamat forráskódot használ, vagy az Azure Reposban van definiálva, teljes mértékben ismernie kell az Azure Repos engedélymodellt. Az adattár szintjén fiók létrehozása engedéllyel rendelkező felhasználók akkor is bevezethetnek kódot az adattárba, ha a felhasználó nem rendelkezik Közreműködői engedéllyel.

Egyéb biztonsági szempontok

A folyamatok biztonságossá tétele során az alábbi néhány dolgot érdemes figyelembe vennie.

A PATH-ra támaszkodva

Az ügynök PATH beállítására támaszkodni veszélyes. Lehet, hogy nem arra mutat, ahol gondolja, mivel egy korábbi szkript vagy eszköz esetleg módosította. A biztonsági szempontból kritikus szkriptekhez és bináris fájlokhoz mindig használjon teljes elérési utat a programhoz.

Titkos kulcsok naplózása

Az Azure Pipelines lehetőség szerint megpróbálja megtisztítani a naplók titkos kulcsait. Ez a szűrés a lehető legjobban működik, és nem tud minden olyan módon elfogni, hogy a titkos kulcsok kiszivároghatnak. Ne visszhangozza a titkos kulcsokat a konzolon, használja őket parancssori paraméterekben, és ne naplózhassa őket fájlokba.

Tárolók zárolása

A tárolók néhány rendszer által biztosított kötetcsatlakozási leképezéssel rendelkeznek a feladatokban, a munkaterületen és a gazdaügynökkel való kommunikációhoz szükséges külső összetevőkben. Ezeket a köteteket írásvédettként is megjelölheti.

resources:
  containers:
  - container: example
    image: ubuntu:22.04
    mountReadOnly:
      externals: true
      tasks: true
      tools: true
      work: false  # the default; shown here for completeness

A legtöbb embernek általában az első három könyvtárat írásvédettként kell beállítania, és írásvédettként kell hagynia work . Ha nem egy adott feladatban vagy lépésben ír a work könyvtárba, nyugodtan írásvédetté is teheti work . Ha azonban a folyamatfeladatok önmódosítást igényelnek, előfordulhat, hogy írásvédettnek kell maradnia tasks .

Az elérhető tevékenységek szabályozása

Letilthatja a feladatokat a Marketplace-ről való telepítésre és futtatásra, így nagyobb mértékben szabályozhatja a folyamatban végrehajtott kódot. Az összes beépített feladatot is letilthatja (kivéve a Kivételt, amely az ügynök speciális művelete). Javasoljuk, hogy a legtöbb esetben ne tiltsa le a beépített feladatokat.

A közvetlenül telepített tfx feladatok mindig elérhetők. Ha mindkét funkció engedélyezve van, csak ezek a feladatok érhetők el.

A naplózási szolgáltatás használata

A naplózási szolgáltatás számos folyamateseményt rögzít. Rendszeresen tekintse át a naplózási naplót, hogy ne csúsztasson át rosszindulatú módosításokat. Látogasson el https://dev.azure.com/ORG-NAME/_settings/audit az első lépésekhez.

Következő lépések

A biztonsági áttekintés áttekintése