Megosztás a következőn keresztül:

Ajánlott biztonsági eljárások

  • Cikk

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Amikor információkat és adatokat kezel, különösen egy felhőalapú megoldásban, például az Azure DevOps Servicesben, a biztonság legyen a legfontosabb. Bár a Microsoft biztosítja a mögöttes felhőinfrastruktúra biztonságát, az Azure DevOpson belüli biztonság konfigurálása az Ön feladata.

Bár nem kötelező, az ajánlott eljárások beépítése jelentősen javíthatja a felhasználói élményt és növelheti a biztonságot. Az alábbi javaslatok célja a biztonságos Azure DevOps-környezet fenntartása.

Az Azure DevOps-környezet védelme

Az alábbi ajánlott eljárásokat alkalmazhatja a felhasználók eltávolításához, a naplózási események áttekintéséhez és a Microsoft Entra-azonosítóval való integrációhoz.

Felhasználók eltávolítása

  • Inaktív felhasználók eltávolítása AZ MSA-fiókokból:
  • Microsoft Entra felhasználói fiókok letiltása vagy törlése:
    • Ha szervezete csatlakozik a Microsoft Entra-azonosítóhoz, letilthatja vagy törölheti a Microsoft Entra felhasználói fiókot, miközben az Azure DevOps felhasználói fiókja aktív marad.
    • Ezzel a módszerrel folytathatja a munkaelemek előzményeinek lekérdezését az Azure DevOps felhasználói azonosítójával.
  • Felhasználói PAT-k visszavonása:
    • A meglévő felhasználói PAT-k rendszeres áttekintése és visszavonása.
    • A PAT-k kritikus hitelesítési jogkivonatok, és a biztonságos kezelésük elengedhetetlen.
  • Az egyes felhasználók számára megadott különleges engedélyek visszavonása:
    • Az egyes felhasználói fiókokhoz adott különleges engedélyek naplózása és visszavonása.
    • Győződjön meg arról, hogy az engedélyek összhangban vannak a minimális jogosultság elvével.
  • A munka újbóli hozzárendelése az eltávolított felhasználóktól:
    • A felhasználók eltávolítása előtt rendelje hozzá újra a kezelt munkaelemeket.
    • Ossza el a számítási feladatot a jelenlegi csapattagok között.

A Microsoft Entra-azonosító használata

  • Egysíkú identitás:
    • Az Azure DevOps és a Microsoft Entra ID összekapcsolásával egységes identitásrendszert hoz létre.
    • A szolgáltatások konzisztenciája csökkenti a zavart, és minimalizálja a manuális konfigurációs hibákból eredő biztonsági kockázatokat.
  • Végpontok közötti szabályozás:
    • A Microsoft Entra ID használatával részletes szabályozást valósíthat meg.
    • Különböző szerepkörök és engedélyek hozzárendelése adott Microsoft Entra-csoportokhoz különböző erőforrás-hatókörökben.
    • Ez a megközelítés biztosítja a szabályozott hozzáférést, és megfelel a biztonsági ajánlott eljárásoknak.
  • Biztonsági funkciók:
    • A Microsoft Entra ID további biztonsági funkciókat tesz lehetővé, például:
      • Többtényezős hitelesítés (MFA): A felhasználói hitelesítés javítása több tényező (például jelszó- és telefonhitelesítés) megkövetelésével.
      • Feltételes hozzáférési szabályzatok: Hozzáférési szabályok meghatározása feltételek (például hely, eszköz vagy kockázati szint) alapján.

További információért tekintse át az alábbi cikkeket:

Naplózási események áttekintése

Miután a szervezetet a Microsoft Entra támogatotta, végezze el a következő feladatokat a biztonság növelése és a használati minták monitorozása érdekében:

  • Naplózás engedélyezése:
    • A biztonsági házirendek között engedélyezze a naplózást.
    • A naplózás segít nyomon követni és naplózni a felhasználói műveletekkel, engedélyekkel és módosításokkal kapcsolatos eseményeket.
  • Rendszeresen tekintse át az auditeseményeket:
    • Rendszeresen tekintse át a naplót.
    • Keresse meg a váratlan használati mintákat, különösen a rendszergazdák és más felhasználók által.

A hálózatok védelme

Az alábbi funkciók hatékonyan javítják a hálózat biztonságát az Azure DevOps használatakor.

  • IP-engedélyezési lista:
    • Állítson be egy engedélyezési listát az adott IP-címekhez való hozzáférés korlátozásához.
    • Csak megbízható forrásokból érkező forgalom engedélyezése, csökkentve a támadási felületet.
  • Titkosítás:
    • Mindig használjon titkosítást az átvitt és inaktív adatokhoz.
    • A kommunikációs csatornák biztonságossá tételét olyan protokollok használatával, mint a HTTPS.
  • Tanúsítvány érvényesítése:
    • Tanúsítványok érvényesítése kapcsolatok létrehozásakor.
    • Győződjön meg arról, hogy a tanúsítványok érvényesek, és megbízható hatóságok állítják ki.
  • Webalkalmazási tűzfalak (WAF-ek):
    • WAF-eket implementálhat a rosszindulatú webes forgalom szűréséhez, monitorozásához és letiltásához.
    • A WAF-k további védelmi réteget biztosítanak a gyakori támadások ellen.

További információkért tekintse meg az alkalmazáskezelés ajánlott eljárásait.

Hatókörön belüli engedélyek

A rendszer különböző szinteken (egyéni, gyűjtemény, projekt és objektum) kezeli az engedélyeket, és alapértelmezés szerint egy vagy több beépített csoporthoz rendeli őket. A biztonság növelése érdekében hajtsa végre a következő műveleteket:

  • A minimális jogosultsági hozzáférés biztosítása: A felhasználók és a szolgáltatások számára a minimálisan szükséges hozzáférést biztosítják az üzleti feladataik elvégzéséhez.
  • Öröklés letiltása:
    • Ha lehetséges, tiltsa le az öröklést.
    • Az öröklés véletlenül hozzáférést vagy engedélyeket adhat a váratlan felhasználóknak az alapértelmezett engedélyezési jellege miatt.
    • További információkért tekintse meg az engedélyöröklésről szóló szakaszt

Az engedélyekkel kapcsolatos további információkért tekintse meg a következő cikkeket:

Projektszintű engedélyek

  • Projektekhez és adattárakhoz való hozzáférés korlátozása:
    • A bizalmas információk kiszivárgásának és a nem biztonságos kód éles környezetben való üzembe helyezésének kockázatának csökkentése érdekében korlátozza a projektekhez és adattárakhoz való hozzáférést.
    • Az engedélyek kezeléséhez használja a beépített biztonsági csoportokat vagy az egyéni biztonsági csoportokat. További információ: Engedélyek megadása vagy korlátozása adott tevékenységekre.
  • Tiltsa le a "Nyilvános projektek engedélyezése" lehetőséget:
    • A szervezet szabályzatbeállításaiban tiltsa le a nyilvános projektek létrehozásának lehetőségét.
    • Az Azure DevOps Services lehetővé teszi a projekt láthatóságának nyilvánosról privátra váltását (és fordítva).
    • Azok a felhasználók, akik még nem jelentkeztek be a szervezetbe, írásvédett hozzáféréssel rendelkeznek a nyilvános projektekhez.
    • A bejelentkezett felhasználók hozzáférést kaphatnak a magánprojektekhez, és engedélyezett módosításokat hajthatnak végre.
  • Projekt létrehozásának korlátozása:
    • Megakadályozza, hogy a felhasználók új projekteket hozzanak létre, hogy fenntartsák az irányítást a környezet felett.

Külső vendéghozzáférés

  • Külső vendéghozzáférés letiltása:
  • Használjon másik e-mailt vagy UPN-t személyes és üzleti fiókjaihoz:
    • Annak ellenére, hogy engedélyezett, használjon különböző e-mail-címeket vagy egyszerű felhasználóneveket (UPN-eket) személyes és üzleti fiókokhoz.
    • Ez a gyakorlat kiküszöböli a kétértelműséget a személyes és a munkahelyi fiókok közötti egyértelműség esetén.
  • Külső vendégfelhasználók csoportosítása:
    • Helyezze az összes külső vendégfelhasználót egyetlen Microsoft Entra-csoportba.
    • A csoport engedélyeinek megfelelő kezelése.
    • Távolítsa el a közvetlen hozzárendeléseket, hogy a csoportszabályok vonatkozzanak ezekre a felhasználókra. További információ: Csoportszabály hozzáadása hozzáférési szintek hozzárendeléséhez.
    • A Szabályok rendszeres újraértékelése a Felhasználók lap Csoportszabályok lapján. Fontolja meg a Microsoft Entra ID-ban a csoporttagság olyan módosításait, amelyek hatással lehetnek a szervezetre. A Microsoft Entra-azonosító akár 24 órát is igénybe vehet a dinamikus csoporttagság frissítéséhez. A rendszer 24 óránként automatikusan újraértékesíti a szabályokat, és minden alkalommal, amikor egy csoportszabály megváltozik.

További információ: B2B-vendégek a Microsoft Entra-azonosítóban.

Biztonsági csoportok kezelése

Biztonsági és felhasználói csoportok

Az alábbi táblázat a biztonsági csoportokhoz és felhasználói csoportokhoz való engedélyek hozzárendelésére vonatkozó javaslatokat mutatja be.

Csinál Nem
Sok felhasználó kezelésekor használja a Microsoft Entra-azonosítót, az Active Directoryt vagy a Windows biztonsági csoportokat. Ne módosítsa a Project Valid Users csoport alapértelmezett engedélyeit. Ez a csoport hozzáférhet és megtekintheti a projektinformációkat.
Csapatok hozzáadásakor vegye figyelembe, hogy milyen engedélyeket szeretne hozzárendelni a csoport azon tagjaihoz, akiknek területelérési utakat, iterációs útvonalakat és lekérdezéseket kell létrehozniuk és módosítaniuk. Ne adjon hozzá felhasználókat több olyan biztonsági csoporthoz, amelyek különböző jogosultsági szinteket tartalmaznak. Bizonyos esetekben a Megtagadás engedélyszint felülírhat egy Engedélyezési jogosultsági szintet.
Ha több csoportot vesz fel, érdemes lehet létrehoznia egy egyéni csoportgazdákat, ahol lefoglalhatja a Projektgazdák számára elérhető engedélyek egy részhalmazát. Ne módosítsa az alapértelmezett hozzárendeléseket a Project Valid Users csoportokhoz . Ha eltávolítja vagy Letiltás értékre állítja a példányszintű információkat a Project Valid Users csoport egyikében, a csoport egyik felhasználója sem férhet hozzá bármilyen projekthez, gyűjteményhez vagy üzembe helyezéshez, amelyen beállította az engedélyt.
Fontolja meg a munkaelem-lekérdezési mappák közreműködési engedélyének megadását azon felhasználók vagy csoportok számára, akik a projekthez munkaelem-lekérdezések létrehozására és megosztására van szükségük. Ne rendeljen hozzá olyan engedélyeket, amelyek csak szolgáltatásfiókokhoz rendelhetők hozzá felhasználói fiókokhoz.
Tartsa a csoportokat a lehető legkisebbre. A hozzáférést korlátozni kell, és a csoportokat gyakran naplózni kell.
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.

További információ: Érvényes felhasználói csoportok.

Igény szerint történő hozzáférés rendszergazdai csoportok számára

Ha rendelkezik projektgyűjtemény-rendszergazdai és projektadminisztrátori hozzáféréssel, módosíthatja a szervezet vagy projekt konfigurációját. Ezeknek a beépített rendszergazdai csoportoknak a biztonsága érdekében érdemes lehet a Microsoft Entra Privileged Identity Management (PIM) csoport használatával igény szerinti hozzáférést implementálni. Ez a módszer lehetővé teszi, hogy csak szükség esetén adjon emelt szintű engedélyeket, csökkentve az állandó hozzáféréssel járó kockázatot.

Hozzáférés konfigurálása

  1. Szerepkörhöz hozzárendelhető csoport létrehozása a Microsoft Entra-azonosítóban.
  2. Adja hozzá a Microsoft Entra-csoportot az Azure DevOps-csoporthoz.

Feljegyzés

Ha a Microsoft Entra Privileged Identity Management (PIM) csoport használatával konfigurálja az igény szerinti hozzáférést, győződjön meg arról, hogy minden emelt szintű hozzáféréssel rendelkező felhasználó is megtartja a szervezethez való szabványos hozzáférést. Így megtekinthetik a szükséges lapokat, és szükség szerint frissíthetik az engedélyeiket.

Hozzáférés használata

  1. Aktiválja a hozzáférést.
  2. Frissítse az engedélyeket az Azure DevOpsban.
  3. A rendszergazdai hozzáférést igénylő művelet végrehajtása.

Feljegyzés

A felhasználók a PIM-csoport hozzáférésének inaktiválása után legfeljebb 1 óráig emelt szintű hozzáféréssel rendelkeznek az Azure DevOpsban.

Hatókör-szolgáltatásfiókok

  • Szolgáltatásfiókok ismertetése
  • Egycélú szolgáltatásfiókok létrehozása:
    • Minden szolgáltatásnak dedikált fiókkal kell rendelkeznie a kockázat minimalizálása érdekében.
    • Kerülje a normál felhasználói fiókok szolgáltatásfiókként való használatát.
  • Kövesse az elnevezési és dokumentációs egyezményeket:
    • Használjon egyértelmű, leíró neveket a szolgáltatásfiókokhoz.
    • Dokumentálja a céljukat és a kapcsolódó szolgáltatásokat.
  • A nem használt szolgáltatásfiókok azonosítása és letiltása:
    • Rendszeresen tekintse át és azonosítsa a már nem használt fiókokat.
    • Tiltsa le a nem használt fiókokat, mielőtt megfontolná a törlést.
  • Jogosultságok korlátozása:
    • Korlátozza a szolgáltatásfiókok jogosultságait a szükséges minimálisra.
    • Kerülje a szolgáltatásfiókok interaktív bejelentkezési jogosultságainak használatát.
  • Használjon külön identitásokat a jelentésolvasók számára:
    • Ha tartományi fiókokat használ a szolgáltatásfiókokhoz, használjon másik identitást a jelentésolvasók számára.
    • Az engedélyek elkülönítése a szükségtelen hozzáférés megakadályozása érdekében. További információ: Szolgáltatásfiókok és függőségek.
  • Használjon helyi fiókokat munkacsoport-telepítésekhez:
    • Ha összetevőket telepít egy munkacsoportba, használjon helyi fiókokat a felhasználói fiókokhoz.
    • Ebben a forgatókönyvben kerülje a tartományi fiókokat. További információ: Szolgáltatásfiókok követelményei.
  • Szolgáltatáskapcsolatok kihasználása:
    • Amikor csak lehetséges, használjon szolgáltatáskapcsolatokat.
    • Biztonságos módot biztosítanak a szolgáltatásokhoz való csatlakozásra anélkül, hogy titkos változókat adnak át közvetlenül a buildekhez.
    • A kapcsolatok korlátozása adott használati esetekre.
  • Szolgáltatásfiók-tevékenység figyelése:

További információ: Common service connection types.

Hatókörszolgáltatás-kapcsolatok

  • Hatókör Azure Resource Manager-szolgáltatáskapcsolatok :
    • A hozzáférés korlátozásához hatókörbe kell szorítani a szolgáltatáskapcsolatokat adott erőforrásokra és csoportokra. Ne adjon széles körű közreműködői jogokat a teljes Azure-előfizetéshez.
    • Számítási feladatok identitás-összevonásának használata a hitelesítéshez. Ez lehetővé teszi a titkos kulcs nélküli szolgáltatáskapcsolatokat az Azure Pipelinesban.
  • Számítási feladatok identitás-összevonásának használata:
    • A számítási feladatok identitásának összevonása Az OpenID Connect (OIDC) használatával titkos kulcsok használata nélkül hitelesíthető az Azure-erőforrásokkal.
    • A számítási feladatok identitásának összevonását automatikusan vagy manuálisan is létrehozhatja. Fontolja meg ezt a megközelítést, ha:
      • Ön az Azure-előfizetése Tulajdonos szerepkörével rendelkezik.
      • Nem csatlakozik az Azure Stackhez vagy az Azure US Government-környezetekhez.
      • A Marketplace-bővítmények által használt tevékenységek támogatják a számítási feladatok identitásának összevonását1.
  • Erőforráscsoport hatóköre:
    • Győződjön meg arról, hogy az erőforráscsoport csak a virtuális gépeket (virtuális gépeket) vagy a buildelési folyamathoz szükséges erőforrásokat tartalmazza.
  • Kerülje a klasszikus Azure-szolgáltatáskapcsolatokat:
    • A klasszikus szolgáltatáskapcsolatok nem rendelkeznek hatókörkezelési lehetőségekkel. Ehelyett válasszon modern Azure Resource Manager-szolgáltatáskapcsolatokat.
  • Célspecifikus csapatszolgáltatás-fiókok használata:
    • A szolgáltatáskapcsolatok hitelesítése célspecifikus csapatszolgáltatás-fiókokkal a biztonság és az ellenőrzés fenntartása érdekében.

További információ: Common service connection types.

A megfelelő hitelesítési módszer kiválasztása

Válassza ki a hitelesítési módszereket a következő forrásokból:

Szolgáltatásnevek megfontolása

Ismerje meg az olyan alternatívákat, mint a szolgáltatásnevek és a felügyelt identitások:

  • Szolgáltatásnevek:
    • Biztonsági objektumokat jelöl egy Microsoft Entra-alkalmazásban.
    • Határozza meg, hogy egy alkalmazás mit tehet egy adott bérlőben.
    • Beállítás az alkalmazásregisztráció során az Azure Portalon.
    • Az Azure-erőforrások, köztük az Azure DevOps elérésére van konfigurálva.
    • Olyan alkalmazások esetében hasznos, amelyekhez meghatározott hozzáférésre és vezérlésre van szükség.
  • Felügyelt identitások:
    • Hasonló az alkalmazás szolgáltatásnevéhez.
    • Adja meg az Azure-erőforrások identitását.
    • Engedélyezi a Microsoft Entra-hitelesítést támogató szolgáltatások számára a hitelesítő adatok megosztását.
    • Az Azure automatikusan kezeli a hitelesítő adatok kezelését és elforgatását.
    • Ideális, ha zökkenőmentes bejelentkezési adatok kezelésére van szüksége.

PAT-k takarékos használata

  • Hatókör paT-jai adott szerepkörökre:
    • Csak az adott tevékenységekhez szükséges engedélyeket rendelje hozzá a paT-okhoz. Ne adjon globális hozzáférést több szervezetnek vagy adattárnak.
    • A paT-k hatókörének meghatározása biztosítja, hogy a szükséges minimális jogosultságokkal rendelkezzenek, ezáltal csökkentve a véletlen visszaélés kockázatát.
  • A buildekre és kiadásokra vonatkozó engedélyek írásának és kezelésének elkerülése:
    • A PAT-eknek nem szabad írási vagy kezelési engedélyekkel rendelkezniük a buildekhez, kiadásokhoz vagy egyéb kritikus erőforrásokhoz.
    • Ezeknek az engedélyeknek a korlátozása segít megelőzni azokat a nem szándékos műveleteket, amelyek hatással lehetnek a folyamatokra vagy az üzemelő példányokra.
  • Adja meg a lejárati dátumokat, és tartsa titokban a PAT-okat:
    • Mindig állítson be lejárati dátumot a PAT-k számára. Szükség szerint rendszeresen tekintse át és újítsa meg őket.
    • A PAT-k kritikus fontosságúak, mint a jelszavak. Tartsa őket bizalmasan, és ne ossza meg őket nyilvánosan, vagy ne írja be őket az alkalmazáskódba.
  • Kerülje az alkalmazáskódban lévő paT-k keménykódolását:
    • Bár kényelmesnek tűnhet, kerülje a PAT-k közvetlen beágyazását a kódba.
    • Ehelyett használjon biztonságos konfigurációs fájlokat vagy környezeti változókat a PAT-k dinamikus tárolásához és lekéréséhez.
  • A nem használt PAT-k rendszeres naplózása és visszavonása:
    • A rendszergazdáknak rendszeresen ellenőriznie kell az összes PAT-t a REST API-k használatával.
    • Vonja vissza azokat a paT-okat, amelyekre már nincs szükség, vagy amelyek nem felelnek meg az ajánlott feltételeknek.

További információkért tekintse meg a következő cikkeket:

Az Azure Artifacts biztonságossá tétele

Az Azure Boards biztonságossá tétele

Az Azure Pipelines biztonságossá tétele

Szabályzatok

  • Az eredeti kérelmezőn kívüli véleményezők megkövetelése:
    • Ha legalább egy véleményező az eredeti kérelmezőn kívül van, az alaposabb felülvizsgálati folyamatot biztosítja.
    • A jóváhagyó osztozik a módosítások közös tulajdonjogán, és minden lehetséges hatásért egyenlően elszámoltathatónak kell lennie.
  • A CI-build átadásának megkövetelése:
    • A kódminőség alapkonfigurációját a folyamatos integrációs (CI) build egyesítése előtt kell elvégezni.
    • A CI-ellenőrzések közé tartozik a kódszélesítés, az egységtesztek és a biztonsági vizsgálatok (például a vírus- és hitelesítő adatok ellenőrzése).
  • Az eredeti kérelmező általi önjóváhagyás letiltása:
    • Megakadályozza, hogy az eredeti KÉRELEM-kérelmező jóváhagyja a saját módosításait.
    • Ez a művelet biztosítja az elfogulatlan felülvizsgálati folyamatot, és elkerüli a lehetséges összeférhetetlenségeket.
  • A "várakozás" vagy az "elutasítás" szavazatok esetén is tiltsa le a PR-befejezést:
    • Még akkor is, ha egyes véleményezők a várakozásra vagy elutasításra szavaznak, megakadályozzák a pr befejezését.
    • Ez a művelet arra ösztönöz, hogy az egyesítés előtt minden visszajelzést kezeljen.
  • A kód felülvizsgálója a leküldéses módosításokra vonatkozó szavazatok alaphelyzetbe állítása:
    • Amikor a legutóbbi módosításokat leküldi a lekéréses kérelemre, állítsa vissza a felülvizsgáló szavazatát.
    • Ez a művelet biztosítja, hogy a felülvizsgálók újra kiértékeljék a frissített kódot.
  • A kiadási folyamatok zárolása adott éles ágakra:
    • A kiadási folyamatokat meghatározott ágakra korlátozza (általában éles vagy fő).
    • Kerülje a véletlen üzembe helyezéseket más ágakból.
  • Settable változók kényszerítése várakozási időben:
    • Engedélyezze a "Settable kényszerítése üzenetsor idején" beállítást a folyamatváltozókhoz.
    • Ez a művelet megakadályozza, hogy a felhasználók felülírják a változó értékeket a folyamat végrehajtása során.
  • A változó felülbírálásának letiltása a szerkesztőben:
    • A folyamatszerkesztőben beállított változók esetében tiltsa le a felhasználói felülbírálásokat.
    • Ez a művelet fenntartja a konzisztenciát, és megakadályozza a nem szándékos módosításokat.

Ügynökök

  • Engedélyek megadása takarékosan:
    • Korlátozza az engedélyeket a legkisebb szükséges fiókkészletre.
    • Kerülje a túlzottan megengedő hozzáférést, csökkentve a támadási felületet.
  • A használható ügynökökre vonatkozó korlátozó tűzfalak:
    • Konfigurálja úgy a tűzfalakat, hogy a lehető legszigorúsabbak legyenek, miközben továbbra is lehetővé teszik az ügynökök működését.
    • Egyensúlyt teremt a biztonság és a használhatóság között.
  • Ügynökkészletek rendszeres frissítése:
    • Az ügynökök rendszeres frissítésével naprakészen tarthatja ügynökflottát.
    • Ez a művelet biztosítja, hogy a sebezhető kód ne fusson, így csökken a kihasználtság kockázata.
  • Külön ügynökkészlet az éles összetevőkhöz:
    • Használjon egy különálló ügynökkészletet az éles használatra szánt buildösszetevőkhez.
    • Az éles összetevők elkülönítése segít megelőzni a nem éles ágak véletlen üzembe helyezését.
  • Szegmensérzékeny készletek:
    • Hozzon létre külön készleteket a bizalmas és nem érzékeny számítási feladatokhoz.
    • Csak a megfelelő készlethez társított builddefiníciókban engedélyezze a hitelesítő adatokat.

Definíciók

  • A YAML használata folyamatdefiníciókhoz:
    • A YAML (Még egy korrektúranyelv) a folyamatok definiálása során javasolt módszer.
    • Nyomon követhetőséget biztosít a módosításokhoz, ami megkönnyíti a módosítások nyomon követését az idő múlásával.
    • Emellett a YAML-folyamatok betarthatják a jóváhagyási irányelveket és a verziókövetési eljárásokat.
  • A folyamatdefiníciók szerkesztési hozzáférésének korlátozása:
    • A folyamatdefiníciók szerkesztéséhez való hozzáférés korlátozása a minimálisan szükséges fiókokra.
    • Ezzel csökkentheti a véletlen vagy jogosulatlan módosítások kockázatát.

Bevitel

  • A buildszkriptek változóinak józansági ellenőrzésének belefoglalása:
    • A buildszkripteken belül józansági ellenőrzéseket hajthat végre a parancsinjektálási támadások beállítási változókon keresztüli csökkentése érdekében.
    • Ezek az ellenőrzések ellenőrizhetik a bemeneti értékeket, és megakadályozhatják a nem szándékos vagy rosszindulatú parancsokat.
  • A "settable at release time" buildváltozók számának korlátozása:
    • Állítsa be a lehető legkevesebb buildváltozót a "settable at release time" (Beállítás a kiadás időpontjában) értékre.
    • Az ilyen változók számának minimalizálása csökkenti a támadási felületet, és leegyszerűsíti a konfigurációkezelést.

Tevékenységek

  • Kerülje a távolról lekért erőforrásokat:
    • Amikor csak lehetséges, ne kérje le az erőforrásokat külső URL-címekről a buildelési folyamat során.
    • Ha távoli erőforrásokra van szükség, használja a verziószámozást és a kivonat-ellenőrzést az integritás biztosításához.
  • Kerülje a titkos kulcsok naplózását:
    • A buildnaplókban soha ne naplózza a bizalmas információkat, például titkos kulcsokat vagy hitelesítő adatokat.
    • A naplózási titkos kódok véletlenül elérhetővé tehetik őket, és veszélyeztethetik a biztonságot.
  • Titkos kódokhoz használja az Azure Key Vaultot:
    • A titkos kulcsok közvetlenül a folyamatváltozókban való tárolása helyett használja az Azure Key Vaultot.
    • A Key Vault biztonságos módot biztosít a titkos kódok központi kezelésére és lekérésére.
  • A futó buildek korlátozása tetszőleges ágakra vagy címkékre:
    • A biztonsági szempontból kritikus fontosságú folyamatok esetében korlátozza a felhasználókat a buildek bármely ágon vagy címkén való futtatásában.
    • Meghatározott engedélyezett ágakat vagy címkéket határozhat meg a véletlen vagy jogosulatlan végrehajtások megakadályozása érdekében.
  • Folyamatengedélyek öröklésének letiltása:
    • Az örökölt engedélyek túl szélesek lehetnek, és nem feltétlenül tükrözik pontosan az igényeiket.
    • Tiltsa le az öröklést, és állítsa be az engedélyeket kifejezetten a biztonsági követelményeknek megfelelően.
  • Feladat-engedélyezési hatókörök korlátozása:
    • Mindig a szükséges minimálisra korlátozza a feladat-engedélyezési hatóköröket.
    • Az engedélyek finomhangolása az egyes feladatok által végrehajtott konkrét feladatok alapján.

Adattárak és ágak

  • A véleményezők minimális számának megkövetelése:
    • Engedélyezze a "Véleményezők minimális számának megkövetelése" szabályzatot annak biztosításához, hogy minden lekéréses kérelem legalább két jóváhagyótól kapjon felülvizsgálatot.
    • Ez elősegíti a kód alapos felülvizsgálatát és elszámoltathatóságát.
  • Tárházspecifikus biztonsági szabályzatok konfigurálása:
    • Projektszintű szabályzatok helyett a biztonsági szabályzatokat az egyes adattárakhoz vagy ágakhoz kell igazítani.
    • A testreszabott szabályzatok csökkentik a kockázatokat, betartatják a változáskezelési szabványokat, és javítják a kódminőséget.
  • Éles titkos kulcsok elkülönítése egy külön kulcstartóban:
    • Az éles titkos kulcsokat külön tárolhatja egy Azure Key Vaultban.
    • Korlátozza a szükséges alaphoz való hozzáférést, hogy fenntartsa a nem éles buildektől való elkülönítést.
  • Tesztkörnyezetek elkülönítése az éles környezetektől:
    • Kerülje a tesztkörnyezetek és az éles környezetek keverését.
    • Győződjön meg arról, hogy a hitelesítő adatokat és titkos kulcsokat nem éles környezetben használják.
  • Elágaztatás letiltása:
    • Az elágaztatás letiltása segít a biztonság kezelésében.
    • Az elágazások elszaporodhatnak, így nehéz nyomon követni az összes példány biztonságát.
  • Kerülje az elágazás-buildek titkos kulcsainak megadását:
    • Ne ossza meg a titkos kulcsokat elágazott buildekkel.
    • A titkos kódoknak bizalmasnak kell lenniük, és nem szabad elágazásoknak kitéve lenniük.
  • Fontolja meg az elágaztatási buildek manuális aktiválását:
    • Az automatikus eseményindítók engedélyezése helyett manuálisan aktiválja az elágazásokhoz készült buildeket.
    • Ez jobb ellenőrzést biztosít a biztonsági ellenőrzések felett.
  • A Microsoft által üzemeltetett ügynökök használata elágazás-buildekhez:
    • Használja a Microsoft által üzemeltetett ügynököket az elágazott buildekhez.
    • Ezeket az ügynököket karbantartjuk és biztonságban tartjuk.
  • Éles builddefiníciók vizsgálata a Git-adattárakban:
    • Rendszeresen ellenőrizze a projekt Git-adattárában tárolt éles builddefiníciókat.
    • Keressen bármilyen hitelesítő adatot vagy bizalmas információt.
  • Az éles környezet ágvezérlési ellenőrzésének konfigurálása:
    • Az elágaztatás-vezérlési ellenőrzések beállításával korlátozhatja a bizalmas kapcsolatok (például a prod-connection) használatát az éles ág környezetében futó folyamatokra.
    • Ez biztosítja a megfelelő engedélyezést, és megakadályozza a véletlen visszaélést.

További információ: Egyéb biztonsági szempontok.

Az Azure-adattárak biztonságossá tétele

Azure-tesztcsomagok biztonságossá tétele

GitHub-integrációk biztonságossá tétele

  • Használjon OAuth-folyamatot PAT-k helyett:
    • Tiltsa le a PAT-alapú hitelesítést a GitHub-szolgáltatáskapcsolatok esetében.
    • Válassza az OAuth-folyamatot, amely jobb biztonságot és integrációt biztosít.
  • Kerülje a rendszergazdai vagy tulajdonosi identitásokat:
    • Soha ne hitelesítse a GitHub-szolgáltatáskapcsolatokat olyan identitással, amely rendszergazda vagy bármely adattár tulajdonosa.
    • Korlátozza az engedélyeket a szükséges szintre.
  • Kerülje a teljes hatókörű GitHub-PAT-okat:
    • Ne használjon teljes hatókörű GitHub PAT-t a szolgáltatáskapcsolatok hitelesítéséhez.
    • Használjon jogkivonatokat a minimálisan szükséges engedélyekkel.
  • Kerülje a személyes GitHub-fiókokat szolgáltatáskapcsolatként:
    • Ne használjon személyes GitHub-fiókokat szolgáltatáskapcsolatként az Azure DevOpsban.
    • Ehelyett hozzon létre dedikált szolgáltatásfiókokat, vagy használjon szervezeti szintű fiókokat.