DevOps-környezetek biztonságossá tétele a nulla megbízhatóság érdekében

A DevOps-környezetek biztonságossá tétele már nem választás a fejlesztők számára. A rossz szereplők balra tolódnak, ezért olyan zéró megbízhatósági elveket kell implementálnia, amelyek tartalmazzák a explicit hitelesítést, a minimális jogosultsági hozzáférés használatát és a DevOps-környezetek megsértésének feltételezését.

Ez a cikk a DevOps-környezetek biztonságossá tételének ajánlott eljárásait ismerteti nulla megbízhatósági megközelítéssel, amely megakadályozza, hogy a rossz szereplők veszélyeztetjék a fejlesztői dobozokat, megfertőzzék a kiadási folyamatokat rosszindulatú szkriptekkel, és tesztkörnyezeteken keresztül hozzáférjenek az éles adatokhoz.

A Securing Enterprise DevOps Environments eBook a fejlesztői, DevOps-platform- és alkalmazáskörnyezetek alábbi vizualizációját, valamint az egyes potenciális biztonsági fenyegetéseket tartalmazza.

Az ábra a DevOps-környezeteket és a biztonsági fenyegetéseket mutatja be.

Figyelje meg az előző ábrán, hogy a környezetek és a külső integrációk közötti kapcsolatok hogyan bővítik a fenyegetési környezetet. Ezek a kapcsolatok növelhetik a rossz szereplők számára a rendszer veszélyeztetésére vonatkozó lehetőségeket.

A rossz szereplők a vállalatokra terjednek ki, hogy veszélybe sodorják a DevOps-környezeteket, hozzáférést szerezzenek, és új veszélyeket oldjanak fel. A támadások túlmutatnak a kiberbiztonsági incidensek tipikus szélességén, hogy rosszindulatú kódot injektáljanak, hatékony fejlesztői identitásokat feltételeznek, és ellopják az éles kódot.

Ahogy a vállalatok mindenhol elérhető, bárhonnan dolgozó forgatókönyvekre váltanak, meg kell erősíteniük az eszközök biztonságát. Előfordulhat, hogy a kiberbiztonsági irodák nem ismerik következetesen, hogy a fejlesztők hol és hogyan védik és fejlesztik a kódot. A rossz szereplők kihasználják ezeket a gyengeségeket a távoli kapcsolati hackekkel és a fejlesztői identitáslopásokkal.

A DevOps-eszközök kulcsfontosságú belépési pontok a rossz szereplők számára, a folyamatautomatizálástól a kódérvényesítésig és a kódtárakig. Ha a rosszindulatú szereplők még az éles rendszerek elérése előtt megfertőzik a kódot, az a legtöbb esetben átjuthat a kiberbiztonsági ellenőrzőpontokon. A kompromittálódás elkerülése érdekében győződjön meg arról, hogy a fejlesztői csapatok szemrevételezésekkel, IDE biztonsági pluginokkal végzett ellenőrzésekkel, biztonságos kódolási szabványokkal és ág-ellenőrzésekkel foglalkoznak.

A kiberbiztonsági csapatok célja annak megakadályozása, hogy a rosszindulatú szereplők éles környezeteket támadjanak. A környezetek azonban már tartalmazzák az ellátási lánc eszközeit és termékeit. A nyílt forráskódú eszközök megsértése fokozhatja a globális kiberbiztonsági kockázatokat.

További információt találhat a fejlesztőkre vonatkozó cikkekről a következő DevSecOps cikkekben, amelyek a Zero Trust Útmutató Központfejlesztői útmutató részében találhatók.

Következő lépések

  • Az Azure DevOps segítségével felgyorsíthatja és biztonságossá teheti a kódot olyan eszközökkel, amelyekkel a fejlesztők a leggyorsabb és legbiztonságosabb kódot hozhatják a felhőbe.
  • Regisztráljon az Azure Developer CLI-re, amely egy nyílt forráskódú eszköz, amely felgyorsítja az Azure használatának megkezdéséhez szükséges időt.
  • Konfigurálja az Azure-t, hogy összevont identitásként megbízható legyen a GitHub OIDC-je. Az OpenID Connect (OIDC) lehetővé teszi, hogy a GitHub Actions-munkafolyamatok anélkül férhessenek hozzá az Azure-beli erőforrásokhoz, hogy hosszú élettartamú GitHub-titkos kulcsként kellene tárolniuk az Azure hitelesítő adatait.
  • A DevOps-erőforrásközpont segítséget nyújt a DevOps-eljárások, az Agile metódusok, a Git-verziókövetés, a Microsoft DevOps szolgáltatása és a szervezet DevOps-folyamatának felmérésében.
  • Megtudhatja, hogy a Microsoft DevSecOps megoldás hogyan integrálja a biztonságot a szoftverkézbesítési életciklus minden aspektusába a DevSecOps vagy a DevOps biztonságossá tétele érdekében a felhőbeli alkalmazások számára (és bárhol) az Azure-ral és a GitHubbal.