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

A folyamat és a CI/CD-munkafolyamat biztonságossá tétele

  • Cikk

Ez a cikk a CI/CD-folyamatok és munkafolyamatok biztonságossá tételét ismerteti.

Az automatizálás és az Agilis módszertan lehetővé teszi, hogy a csapatok gyorsabban teljesíthessenek, de összetettebbé teszik a biztonságot, mivel a munkafolyamat magukra a fejlesztői csapatokra terjed ki.

Az alábbi ábra egy alapkonfigurációs CI/CD-munkafolyamatot szemléltet. A piros konfiguráció ikon a biztonsági engedélyeket jelzi, amelyeket az ügyfélnek kell konfigurálnia. Ez a megosztott felelősségi modellt követi, ahol az Azure és más szállítók biztosítják az engedélyeket, amelyeket az ügyfélnek az irányítási modell és az üzleti követelmények szerint kell konfigurálnia.

Egy tipikus CI/CD-munkafolyamat, amely bemutatja, hogy a Git-adattár kódváltozásai hogyan befolyásolják a felhőbeli erőforrásokat

Vizsgáljuk meg ennek a tipikus munkafolyamatnak minden szakaszát, hogy megérthesse, a konfigurációk gyakran hogyan függnek egymástól. Előfordulhat, hogy a munkafolyamat több fázisból áll. Az alábbi fogalmak segítenek megérteni a CI/CD-t, és megtervezni a munkafolyamatot a biztonság érdekében.

1. szakasz: Git-munkafolyamat

A kódmódosítások nem csak a szoftverre, hanem a kódként és infrastruktúraként történő folyamatra is, a Gitben vannak mentve és felügyelve. A Git egy elosztott forráskódkezelő szoftver. Ha a kód leküldése a helyi számítógépekről a központi Git-kiszolgálóra történik, az elfogadás előtt üzleti szabályok alkalmazhatók.

Lekéréses kérelmek és együttműködés

Az iparági szabvány munkafolyamata, függetlenül attól, hogy a szoftverkonfiguráció-kezelő (SCM) szoftver szolgáltatóként (SaaS)-szállítóként működik-e, lekéréses kérelmeket kell használnia, amelyek automatikus minőségi kapuőrként és manuális jóváhagyási lépésként is működhetnek a forráskód elfogadása előtt.

A lekéréses kérelmek munkafolyamata úgy lett kialakítva, hogy egészséges súrlódást vezessen be, ezért csak bizonyos Git-ágak védelmére érdemes alkalmazni. Különösen azok az ágak, amelyek automatizált munkafolyamatokat aktiválnak, amelyek üzembe helyezhetik, konfigurálhatják vagy bármilyen más módon befolyásolhatják a felhőerőforrásokat. Ezeket az ágakat védett ágaknak nevezzük, és általában az elnevezési konvenciók, például production a .releases/*

Gyakori, hogy a lekéréses kérelmekhez a következőre van szükség:

  • Társértékelések
  • Folyamatos integrációs (CI) buildek átadása
  • Manuális jóváhagyás

Ha a követelmények teljesülnek, a kód módosításai elfogadottak, és egyesíthetők.

Védett ágakhoz való hozzáférés korlátozása

A lekéréses kérelem munkafolyamata korlátozott hozzáférés-vezérléssel együtt használható. A lekéréses kérelem munkafolyamata azonban nem kényszeríthető ki, kivéve, ha a kiszolgáló úgy van konfigurálva, hogy elutasítsa a védett ágak közvetlen módosításait.

A fejlesztő nem tud közvetlenül az production ágra leküldni, hanem létre kell hoznia egy lekéréses kérelmet, amely a védett ágat célozza. Minden SCM-szállító más-más stílusú a védett ágakhoz való korlátozott hozzáférés eléréséhez. A GitHub esetében például ez a funkció csak a GitHub-csapatot vagy a GitHub Enterprise-felhőt használó szervezetek számára érhető el .

A Git hozzáférési modelljének dokumentálása

Mivel az együttműködési modell összetett, és számos mozgó részből áll, hasznos lehet olyan táblázatot létrehozni, amely dokumentálja a kódmódosítások minden lehetséges módját, például az üzembe helyezéseket:

Ág neve Pr-t igényel? Telepíti? Fejlesztői hozzáférés Rendszergazdai hozzáférés
feat/* Nem Nem Olvasható/írható Olvasható/írható
main Igen Előkészítés Olvasás Olvasható/írható
production Igen, main csak Termelés Olvasás Olvasható/írható

Ez a Git-hozzáférési tábla példája túlsimított, hogy bemutassa a célját. A gyakorlatban gyakran több szereplő, több üzembehelyezési cél és több folyamat fut a különböző használati esetekhez. A táblázat struktúrája a szervezet követelményeitől és a számítási feladatoktól függően eltérő lehet.

A táblázatnak segítséget kell nyújtania az olyan kérdések megválaszolásában, mint például:

  • Ha egy fejlesztő leküldi a kód módosításait az X ágba, üzembe helyezi? Ha igen, melyik környezetbe?
  • Az alkalmazáskód életciklusának mely pontján végzett biztonságirés-vizsgálat?
  • Ha biztonsági rést talál, hány kódküldésre és jóváhagyásra van szükség, mielőtt éles környezetbe kerül?

Ez a táblázat nemcsak a hibakereséshez és a statikus dokumentációhoz hasznos, hanem a csapatmunkához is. Ez átlátható a fejlesztők számára, ahol egészséges súrlódások vezettek be a munkafolyamatba a kódminőség és a biztonság rangsorolása érdekében. Ennél is fontosabb, hogy megmutatja a fejlesztőnek a kódmódosítások várható útvonalát, hogy elérjék az éles üzemet.

Mivel a DevOps egy út, a Git-hozzáférési modell nem statikus. Ez változni és fejlődni fog, ahogy a csapatok megtalálják a saját ritmusukat és érettek lesznek. Ezért fontos, hogy ezt a dokumentációt a lehető legközelebb tárolja a kódhoz, például a Git-adattárakban.

A lekéréses kérelmekről és a védett ágakról az alábbiakban talál további információt:

2. szakasz: Folyamatok kódként

A folyamat mint kód mozgatása felgyorsította az automatizálás bevezetését és üzembe helyezését azáltal, hogy a ci-szállítótól a fejlesztőknek áthelyezte a folyamatdefiníciókat és konfigurációkat, így a buildelési és üzembehelyezési logika közelebb kerül a megfelelő alkalmazáslogikához. A nagyobb rugalmasság itt is nagyobb felelősséggel jár.

A felhasználói felületen alapuló folyamatok RBAC-vezérlői megakadályozhatják, hogy az egyes felhasználók romboló módosításokat hajtanak végre. A folyamatokat kódként azonban gyakran emelt szintű identitásokkal futtatják, és ha erre utasítják, megsemmisíthetik a számítási feladatokat.

3. szakasz: Az üzembehelyezési hitelesítő adatok védelme

A folyamatok és a kódtárak nem tartalmazhatnak szigorúan kódolt hitelesítő adatokat és titkos kulcsokat. A hitelesítő adatokat és titkos kulcsokat máshol kell tárolni, és ci-szállítói funkciókat kell használni a biztonság érdekében. Mivel a folyamatok fej nélküli ügynökökként futnak, soha nem használhatják az egyén jelszavát. A folyamatoknak inkább fej nélküli biztonsági tagok használatával kell futniuk, például szolgáltatásnevek vagy felügyelt identitások használatával. A biztonsági tag hitelesítő adataihoz, az adatbázis-kapcsolati sztring és a külső API-kulcsokhoz való hozzáférést a CI-platformon is biztonságosan kell kezelni.

A hitelesítő adatok biztonságának, a kapuk és a jóváhagyások szállítóspecifikus funkciók. A CI-platform kiválasztásakor győződjön meg arról, hogy minden szükséges funkciót támogat.

Az Azure Pipelines egy nagyvállalati szintű folyamatos integrációs megoldás, amelyben a hitelesítő adatok szolgáltatáskapcsolatként vannak tárolva, amelyen jóváhagyásokat és ellenőrzéseket konfigurálhat. Ez a konfiguráció magában foglalja a manuális jóváhagyást és az adott ág- vagy folyamatengedélyeket.

Azure Key Vault

Ha a CI-platform támogatja, fontolja meg a hitelesítő adatok tárolását egy dedikált titkos tárban, például az Azure Key Vaultban. A hitelesítő adatokat futásidőben kéri le a buildügynök, és a támadási felület csökken.

4. szakasz: Az Azure-erőforrások védelme

Az Azure-erőforrásokat a minimális jogosultság elve szerint kell biztosítani, amely az engedélyekre és a hatókörre egyaránt érvényes.

További információk:

Egyéni szerepkörök létrehozása buildügynökökhöz

A CI/CD automatizálás nem csak az alkalmazásokra, hanem az infrastruktúrára is vonatkozik. Az infrastruktúra mint kódsablonok konzisztens üzembe helyezést biztosítanak, és segítenek a központosított felhőplatform-csapatok skálázásában.

Fontos tisztában lenni azzal, hogy az IaC automatizálása hibás lehet. Helytelenül konfigurálhatja, és legrosszabb esetben végleg törölheti az infrastruktúrát. Amikor megtervezi a felhőbeli utazást, előre meg kell határoznia, hogy mely műveletek üzleti szempontból kritikusak, és milyen emberi beavatkozást igényelnek.

Előfordulhat például, hogy a felügyeleti zárolások nem törölhetők az üzletileg kritikus fontosságú erőforrásokra, például adatokra. Ennek megakadályozása érdekében eltávolíthatja Microsoft.Authorization/*/Delete az engedélyeket a CI-automatizálásban használt szolgáltatásnévről. Ebben a példában és használati esetben a szolgáltatásnév létrehozhatja a felügyeleti zárolást, de nem törölheti.

Ajánlott egyéni szerepkört létrehozni a CI-ügynökök számára. Ne feledje, hogy az ügynökök fej nélküliek, a fej nélküli ügynökök pedig agyatlanok. Gondosan válassza ki az engedélyeket.

További információ:

Források

Következő lépések

Most, hogy megismerte a DevOps biztonságossá tételének módját, többet tudhat meg a végpontok közötti szabályozásról a DevOpstól az Azure-on át.

Végpontok közötti szabályozás a DevOpstól az Azure-ba