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óval és adatokkal dolgozik, különösen egy felhőalapú megoldásban, például az Azure DevOps Servicesben, a biztonság prioritásának mindig az elsődleges szempontnak kell lennie. Bár a Microsoft fenntartja a mögöttes felhőinfrastruktúra biztonságát, az Ön felelőssége, hogy konfigurálja a biztonságot az Azure DevOpsban.

Bár ez nem kötelező, az Ajánlott eljárások beépítése az Azure DevOps használata során javíthatja a felhasználói élményt, és biztonságosabbá teheti azt. Az alábbi ajánlott eljárások célja az Azure DevOps-környezet védelme:

Az Azure DevOps-környezet biztonságossá tétele

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

  • Ha a szervezet MSA-fiókokat használ, akkor távolítsa el az inaktív felhasználókat közvetlenül a szervezetből, mivel nincs más módja a hozzáférés megakadályozására. Ha így tesz, nem hozhat létre lekérdezést az eltávolított felhasználói fiókhoz hozzárendelt munkaelemekhez. További információ: Felhasználók törlése az Azure DevOpsból.
  • Ha a szervezet csatlakozik a Microsoft Entra-azonosítóhoz, letilthatja vagy törölheti a Microsoft Entra felhasználói fiókot, és aktív marad az Azure DevOps felhasználói fiókja. Ily módon továbbra is lekérdezheti a munkaelemek előzményeit az Azure DevOps felhasználói azonosítójával.
  • Felhasználói PAT-k visszavonása.
  • Visszavonhatja az egyes felhasználói fiókokhoz adott különleges engedélyeket.
  • Rendelje újra a munkát az eltávolított felhasználókhoz a jelenlegi csapattagok számára.

A Microsoft Entra-azonosító használata

Az Azure DevOps és a Microsoft Entra ID integrálása egyetlen identitássíkkal. A konzisztencia és az egyetlen mérvadó forrás növeli az egyértelműséget, és csökkenti az emberi hibák és a konfiguráció összetettségének biztonsági kockázatait. A végső szabályozás kulcsa, hogy több szerepkör-hozzárendeléssel rendelkezzen (különböző szerepkördefiníciókkal és különböző erőforrás-hatókörökkel ugyanazon Microsoft Entra-csoportokhoz). A Microsoft Entra-azonosító nélkül kizárólag Ön a felelős a szervezeti hozzáférés szabályozásáért.

A Microsoft Entra ID használatával más biztonsági funkciókhoz is hozzáférhet, például többtényezős hitelesítéshez vagy más feltételes hozzáférési szabályzatokhoz.

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

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

Ha már rendelkezik Microsoft Entra által támogatott szervezettel, bekapcsolhatja a naplózást a biztonsági szabályzatokban. Rendszeres időközönként tekintse át a naplózási eseményeket , hogy megfigyelje és reagáljon a rendszergazdák és más felhasználók váratlan használati mintáira.

A hálózatok védelme

Ennek néhány módja a következők lehetnek:

  • Állítson be egy engedélyezési listát adott IP-címek korlátozásához.
  • Mindig használjon titkosítást.
  • Tanúsítványok ellenőrzése.
  • Webalkalmazási tűzfalakat (WAF-eket) implementálhat, így szűrhetik, figyelhetik és blokkolhatják az Azure DevOpsba irányuló és onnan érkező rosszindulatú webes forgalmat.
  • További információkért tekintse meg ezt az útmutatót az alkalmazáskezelés ajánlott eljárásairól

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.

Projektszintű engedélyek

  • Korlátozza a projektekhez és adattárakhoz való hozzáférést 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.
  • 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 a tevékenységek kiválasztásához.
  • Tiltsa le a "Nyilvános projektek engedélyezése" beállítást a szervezet szabályzatbeállításaiban, hogy minden szervezeti felhasználó ne hozzon létre nyilvános projektet. Az Azure DevOps Services lehetővé teszi a projektek láthatóságának módosítását nyilvánosról privátra, és fordítva. Ha a felhasználók nem jelentkeztek be a szervezetbe, írásvédett hozzáféréssel rendelkeznek a nyilvános projektekhez. Ha a felhasználók bejelentkeztek, hozzáférést kaphatnak a magánprojektekhez, és bármilyen engedélyezett módosítást végezhetnek rajtuk.
  • Ne engedélyezze a felhasználóknak, hogy új projekteket hozzanak létre.

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

  • A külső vendéghozzáférés teljes letiltásához tiltsa le a "Meghívások elküldése bármely tartományba" szabályzat letiltásával. Jó ötlet, ha nincs rá üzleti szükség.
  • Használjon másik e-mail- vagy egyszerű felhasználónevet (UPN) a személyes és üzleti fiókjaihoz, annak ellenére, hogy az engedélyezett. Ez a művelet kiküszöböli az üzleti és a személyes fiókok közötti egyértelműség kihívását, ha az e-mail/UPN ugyanaz.
  • Helyezze az összes külső vendégfelhasználót egyetlen Microsoft Entra-csoportba, és megfelelően kezelje a csoport engedélyeit. Így egyszerűen kezelheti és naplózhatja.
    • 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.
    • Rendszeresen értékelje újra a szabályokat a Felhasználók lap Csoportszabályok lapján. Annak tisztázása, hogy a Microsoft Entra ID-ban bekövetkező csoporttagság-változások hatással lehetnek-e a szervezetére. A Microsoft Entra-azonosító akár 24 órát is igénybe vehet a dinamikus csoporttagság frissítéséhez. 24 óránként és a csoportszabály módosításakor a rendszer automatikusan újraértékesíti a szabályokat.
  • 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 engedélyek biztonsági csoportokhoz és felhasználói csoportokhoz való hozzárendeléséhez tekintse meg az alábbi javaslatokat.

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

A szervezet vagy projekt konfigurációját módosíthatja, ha rendelkezik projektgyűjtemény-rendszergazdai és projektadminisztrátori hozzáféréssel. A beépített rendszergazdai csoportokhoz való hozzáférés védelméhez a Microsoft Entra Privileged Identity Management (PIM) csoporttal való igény szerinti hozzáférésre van szükség.

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

Győződjön meg arról, hogy a PIM-csoporttal emelt szintű hozzáféréssel rendelkező felhasználók is rendelkeznek normál hozzáféréssel a szervezethez, hogy megtekinthessék a lapot, hogy frissíthessék 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

  • Győződjön meg arról, hogy a szolgáltatásfiókok nem rendelkeznek interaktív bejelentkezési jogosultságokkal.
  • A szolgáltatásfiókok jogosultságainak korlátozása a minimálisan szükségesre.
  • Használjon másik identitást a jelentésolvasó fiókhoz, ha tartományi fiókokat használ a szolgáltatásfiókokhoz. További információ: Szolgáltatásfiókok és függőségek.
  • Használjon helyi fiókokat felhasználói fiókokhoz, ha egy összetevőt telepít egy munkacsoportba. További információ: Szolgáltatásfiókok követelményei.
  • Lehetőség szerint használjon szolgáltatáskapcsolatokat . A szolgáltatáskapcsolatok biztonságos mechanizmust biztosítanak a válogatott szolgáltatásokhoz való csatlakozáshoz anélkül, hogy titkos változókat kellene közvetlenül átadniuk a buildnek. - Korlátozza ezeket a kapcsolatokat arra a helyre, ahol használni kell őket, és semmi többre.
  • Szolgáltatásfiók-tevékenység figyelése és naplózási stream létrehozása. A naplózással észlelheti és reagálhat a gyanús bejelentkezésekre és tevékenységekre.
  • További információ: Common service connection types.

Hatókörszolgáltatás-kapcsolatok

  • Az Azure Resource Manager és más szolgáltatáskapcsolatok hatóköre csak azokra az erőforrásokra és csoportokra vonatkozik, amelyekhez hozzáférésre van szükségük. A szolgáltatáskapcsolatoknak nem szabad széles körű közreműködői jogosultságokkal rendelkezniük a teljes Azure-előfizetésen.
  • Használjon számítási feladatok identitás-összevonását az Azure Resource Manager-szolgáltatáskapcsolatokhoz. A számítási feladatok identitásának összevonásával titkos kód nélküli szolgáltatáskapcsolatokat hozhat létre az Azure Pipelinesban az Azure-ba.
  • Ne adjon általános vagy széles körű közreműködői jogokat a felhasználóknak az Azure-előfizetéshez.
  • Ne használjon klasszikus Azure-szolgáltatáskapcsolatokat, mert nincs mód az engedélyek hatókörének hatókörére.
  • Győződjön meg arról, hogy az erőforráscsoport csak virtuális gépeket (virtuális gépeket) vagy olyan erőforrásokat tartalmaz, amelyekhez a buildnek hozzá kell férnie.
  • Szolgáltatáskapcsolat hitelesítéséhez használjon célspecifikus csapatszolgáltatás-fiókot.
  • 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

Megismerheti az olyan alternatív megoldásokat, mint a szolgáltatásnevek és a felügyelt identitások , amelyek lehetővé teszik a Microsoft Entra-jogkivonatok használatát az Azure DevOps-erőforrások eléréséhez. Az ilyen jogkivonatok kisebb kockázatot jelentenek, ha kiszivárognak a PAT-khoz képest, és olyan előnyöket tartalmaznak, mint az egyszerű hitelesítő adatok kezelése.

PAT-k takarékos használata

Ha lehetséges, javasoljuk, hogy titkosítási kulcsok helyett mindig használjon identitásszolgáltatásokat a hitelesítéshez, mivel a kulcsok biztonságos kezelése az alkalmazáskóddal kihívást jelent, és olyan hibákhoz vezethet, mint például a bizalmas hozzáférési kulcsok véletlenül közzététele nyilvános kódtárakban, például a GitHubon. Ha azonban személyes hozzáférési jogkivonatokat (PAT-okat) kell használnia, vegye figyelembe az alábbi irányelveket:

  • A PAT-eket mindig adott szerepkörökre kell korlátozni.

  • A PAT-k nem biztosíthatnak globális hozzáférést több szervezet számára.

  • A PAT-k nem adhatnak írási vagy kezelési engedélyeket a buildekhez vagy kiadásokhoz.

  • A PAT-eknek lejárati dátummal kell rendelkezniük, és titkosnak kell lenniük, mivel ugyanolyan kritikus fontosságúak, mint a jelszavak.

  • A PAT-eket soha nem szabad az alkalmazáskódban szigorúan kódolni, még akkor sem, ha ez csábító a kód egyszerűsítése érdekében.

  • A rendszergazdáknak rendszeresen naplózniuk kell az összes PAT-t a REST API-k használatával, és vissza kell vonniuk azokat, amelyek nem felelnek meg a fenti feltételeknek.

  • Tartsa titokban a paT-jait. A jogkivonatok ugyanolyan kritikus fontosságúak, mint a jelszavak.

  • A jogkivonatokat biztonságos helyen tárolhatja.

  • Ne kemény kód jogkivonatokat az alkalmazásokban. Csábító lehet, ha leegyszerűsíti a kód beszerzését egy jogkivonat hosszú ideig történő beszerzéséhez és az alkalmazásban való tárolásához, de ne tegye ezt.

  • Adja meg a jogkivonatok lejárati dátumát.

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

Az Azure Artifacts biztonságossá tétele

  • Győződjön meg arról, hogy tisztában van a hírcsatornák, a projekt és a projektgyűjtemény rendszergazdái közötti különbségekkel. További információ: Azure Artifacts-beállítások konfigurálása.
  • További információ: Csatornaengedélyek beállítása.

Az Azure Boards biztonságossá tétele

Az Azure Pipelines biztonságossá tétele

Szabályzatok

  • Igényeljen legalább egy véleményezőt az eredeti kérelmezőn kívül. A jóváhagyó osztozik a változások tulajdonosi viszonyán, és minden lehetséges hatásért egyenlően elszámoltathatónak kell lennie.
  • A CI-build átadásának megkövetelése. Ez a követelmény hasznos az alapkódminőség meghatározásához kódszélesítéssel, egységtesztekkel és biztonsági ellenőrzésekkel, például vírus- és hitelesítő adatok vizsgálatával.
  • Győződjön meg arról, hogy az eredeti lekéréses kérelmező nem tudja jóváhagyni a módosítást.
  • Tiltsa le a lekéréses kérelem (PR) befejezését, még akkor is, ha egyes véleményezők várakozásra vagy elutasításra szavaznak.
  • A kód felülvizsgálói szavazatának alaphelyzetbe állítása a legutóbbi módosítások leküldésekor.
  • Zárolja a kiadási folyamatokat úgy, hogy csak bizonyos éles ágakon futtatja őket.
  • Engedélyezze a "Settable kényszerítése várólistán a változókhoz" beállítást a szervezet folyamatbeállításaiban.
  • A szerkesztőben beállított változók esetében ne engedélyezze a "Hagyja, hogy a felhasználók felülbírálják ezt az értéket a folyamat futtatásakor".

Ügynökök

  • Adjon engedélyeket a lehető legkisebb számú fiókhoz.
  • Legyen a legkorlátozóbb tűzfal, amely használhatóvá teszi az ügynököket.
  • Rendszeresen frissítse a készleteket, hogy a buildflotta ne fusson olyan sebezhető kódot, amelyet egy rosszindulatú szereplő kihasználhat.
  • Használjon egy külön ügynökkészletet az éles környezetben kiszállított vagy üzembe helyezett buildösszetevőkhöz.
  • Szegmentáljon "bizalmas" készletet a nem érzékeny készletekből, és csak az adott készlethez zárolt builddefiníciókban engedélyezze a hitelesítő adatok használatát.

Definíciók

  • Folyamatdefiníciók kezelése YAML-lel (még egy korrektúranyelv). A YAML a folyamatdefiníciók kezelésének előnyben részesített módszere, mivel nyomon követhető a változásokhoz, és követheti a jóváhagyási irányelveket.
  • A folyamatdefiníció védelme: Hozzáférés szerkesztése a fiókok minimális számához.

Bevitel

  • A buildszkriptekben szereplő változók józansági ellenőrzésének belefoglalása. A józan ész ellenőrzése a parancsinjektálási támadást a beállított változókon keresztül csökkentheti.
  • Állítsa be a lehető legkevesebb buildváltozót a "Settable a kiadás időpontjában" értékre.

Tevékenységek

  • Kerülje a távolról lekért erőforrásokat, de szükség esetén használjon verziószámozást és kivonatolás-ellenőrzést.
  • Ne naplózza a titkos kulcsokat.
  • Ne tárolja a titkos kulcsokat a folyamatváltozókban. Használja az Azure Key Vaultot. Rendszeresen ellenőrizze a buildelési folyamatokat, hogy a titkos kulcsok ne legyenek tárolva a buildelési folyamat változóiban.
  • Ne engedje, hogy a felhasználók tetszőleges ágakon vagy címkéken futtatják a buildeket a biztonsági szempontból kritikus folyamatokon.
  • Tiltsa le az öröklést a folyamaton, mivel az örökölt engedélyek széles körűek, és nem tükrözik pontosan az engedélyekre vonatkozó igényeit.
  • A feladat-engedélyezési hatókörök korlátozása minden esetben.

Adattárak és ágak

  • Állítsa be a "Véleményezők minimális számának megkövetelése" szabályzatot, hogy minden lekéréses kérelmet legalább két jóváhagyó tekintse át.
  • A projekt széles körű használata helyett konfigurálja az egyes adattárakra vagy ágakra vonatkozó biztonsági szabályzatokat. A biztonsági szabályzatok csökkentik a kockázatokat, betartatják a változáskezelési szabványokat, és javítják a csapat kódminőségét.
  • Az éles titkos kulcsokat külön Key Vaultban tárolja, és győződjön meg arról, hogy a hozzáférés csak a szükséges ismeret alapján történik, hogy a nem termelési buildek külön maradjanak.
  • Ne keverje a tesztkörnyezeteket az éles környezetekkel, beleértve a hitelesítő adatok használatát is.
  • Tiltsa le az elágaztatást. Minél több elágazás van, annál nehezebb nyomon követni az egyes villák biztonságát. Emellett a felhasználó könnyedén elágazhatja az adattár másolatát a saját privát fiókjába.
  • Ne adjon titkos kulcsokat az elágazás-buildekhez.
  • Fontolja meg az elágaztatási buildek manuális aktiválását.
  • A Microsoft által üzemeltetett ügynökök használata elágazás-buildekhez.
  • A Git esetében ellenőrizze az éles builddefiníciókat a projekt Git-adattárában, hogy meg lehessen vizsgálni a hitelesítő adatokat.
  • Konfiguráljon egy ágvezérlő-ellenőrzést, hogy csak az ág környezetében production futó folyamatok használhassák a prod-connection.
  • 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

  • Tiltsa le a személyes hozzáférési jogkivonaton (PAT) alapuló hitelesítést, így az OAuth-folyamat a GitHub szolgáltatáskapcsolattal lesz használatban.
  • Soha ne hitelesítse a GitHub-szolgáltatáskapcsolatokat olyan identitásként, amely rendszergazda vagy bármely adattár tulajdonosa.
  • Soha ne használjon teljes hatókörű GitHub PAT-t (személyes hozzáférési jogkivonatot) a GitHub-szolgáltatáskapcsolatok hitelesítéséhez.
  • Ne használjon személyes GitHub-fiókot szolgáltatáskapcsolatként az Azure DevOpsszal.