Miért van szükségük a fejlesztőknek valódi hozzáférés-vezérlési szabályzatokra (nem csak elméletre)?
Ha kódot fejlesztesz, akkor azt karbantartod pipelinevagy az artefaktum-nyilvántartások kezeléséhez többre van szükség, mint elmélet. A gyenge vagy nem definiált hozzáférés-vezérlési szabályzatok elősegítik a tárhely manipulálását, CI/CD visszaélés, és hitelesítő adatok szivárgásaA DevSecOps valódi betartatást követel, nem csak eltemetett jogosultságbeállításokat.
A hozzáférés-vezérlési szabályzatok hatékony kezelése a kódtárak között, CI/CD pipelinesés az artefakt-nyilvántartások miatt sok csapat automatizált végrehajtási eszközökre, például a Xygenire támaszkodik. A szerepkörök, az engedélyek és a szabályzatok betartásának folyamatos monitorozásával a Xygeni segít megelőzni az engedélyek eltolódását, a jogosulatlan hozzáférést és a kézi felülbírálásokat, a kötelező hozzáférés-vezérlés elméletét a gyakorlatba ültetve.
A hozzáférés-vezérlés közvetlenül zárolja a forráskódot, biztosítja a buildeket és védi a termelést pipelineHa a fejlesztők megkerülik a vezérlőket, vagy a szolgáltatásfiókok széleskörű jogosultságokkal rendelkeznek, azzal biztonsági réseket kockáztatnak. Ezért kritikus fontosságú a kötelező hozzáférés-vezérlés, a MAC-hozzáférés-vezérlés és más modellek megértése.
Hozzáférés-vezérlési szabályzatok típusai, amelyeket a fejlesztőknek ismerniük kell
A hozzáférés-vezérlési szabályzatok három fő kategóriába sorolhatók, amelyek mindegyike másképp illeszkedik a CI/CD munkafolyamatok. Íme egy gyors, egymás melletti elemzés a tisztázás érdekében:
| Modell | Ki ellenőrzi a hozzáférést? | Tipikus felhasználás CI/CD | Kockázati szint |
|---|---|---|---|
| DAC (Diszkrecionális hozzáférés-vezérlés) | Erőforrás tulajdonosa (fejlesztő, adminisztrátor) | Repó vagy nyilvántartás hozzáférésének manuális megosztása | Magas (emberi hiba) |
| RBAC (szerepköralapú hozzáférés-vezérlés) | A rendszer szerepkörönként osztja ki az engedélyeket | GitHub ágvédelem, felhasználói szerepkörökön alapuló CI-feladatok elérése | Közepes (helytelenül konfigurált szerepkörök) |
| MAC (kötelező hozzáférés-vezérlés) | Rendszerházirend által érvényesítve | Megköveteli, hogy kik tehetnek közzé összetevőket vagy telepíthetnek kódot | Alacsony (a szabályzat felülírja a felhasználói szándékot) |
A MAC és az RBAC közötti különbségtétel tisztázása CI/CD Kontextus
Könnyű összekeverni a szerepköralapú hozzáférés-vezérlést (RBAC) kötelező hozzáférés-vezérléssel (Mac hozzáférés-vezérlés), különösen a CI/CD környezetekben. Míg CI/CD Az olyan platformok, mint a GitHub és a GitLab, az RBAC-t használják a szerepkörök és engedélyek kezelésére (pl. kik egyesíthetik vagy telepíthetik), ez alapvetően továbbra is szerepkör-alapú, nem pedig valódi MAC hozzáférés-vezérlés.
Az RBAC lehetővé teszi az engedélyek szerepkörök (fejlesztő, karbantartó stb.) alapján történő kiosztását, de ezek az engedélyek továbbra is felhasználó által vezérelhetők és módosíthatók. A helytelen konfigurációk vagy az engedélyek áttérése gyakori kockázatot jelent.
A kötelező hozzáférés-vezérlés (MAC hozzáférés-vezérlés) ezzel szemben rendszer- vagy infrastruktúra-szinten érvényesül. A felhasználók, beleértve az adminisztrátorokat is, nem írhatják felül. A Mac hozzáférés-vezérlésre úgy gondoljon, mint a platformba ágyazott szabályzatokra: IAM-szabályzatok a felhőszolgáltatókban (pl. AWS IAM, GCP IAM), vagy operációs rendszerszintű kényszerítő eszközök, mint például a SELinux vagy az AppArmor. Ezekben az esetekben a hozzáférés csak akkor engedélyezett, ha az előre definiált, nem megkerülhető szabályok teljesülnek.
In CI/CDSzámos eszköz szimulálja a MAC hozzáférés-vezérlési viselkedést szigorúan hatókörű IAM szerepkörökön vagy erőforrás-specifikus engedélyeken keresztül, de ez nem teljes kötelező hozzáférés-vezérlés. A valódi kötelező hozzáférés-vezérlés betartatásához az alkalmazásréteg alatti, az operációs rendszer, a hálózat vagy a felhőinfrastruktúra szintjén lévő vezérlésre van szükség, ahol a hozzáférést megváltoztathatatlan hozzáférés-vezérlési szabályzatok, nem pedig emberi konfiguráció szabályozzák.
Szerep alapú hozzáférés-vezérlés (RBAC)
Az RBAC a jogosultságokat meghatározott szerepkörökhöz, például „fejlesztő”, „karbantartó” vagy „kiadáskezelő” rendeli hozzá. Leegyszerűsíti a kezelést olyan eszközökben, mint a GitHub és a GitLabA felhasználók egyenkénti konfigurálása helyett rendelje hozzájuk egy szerepkört, és hagyja, hogy a rendszer érvényesítse a szabályokat.
Példa: GitHub CODEOWNERS fájl
Ez biztosítja, hogy csak a hozzárendelt szerepkörök hagyhassák jóvá a kritikus könyvtárakban végrehajtott módosításokat.
GitLab szerepkörbeállítások: A projekthez való hozzáférés konfigurálása a Beállítások > Tagok menüpontban:
- Fejlesztő: Képes a kiemelt ágak megjelenítésére.
- Karbantartó: Védett ágakba egyesülhet.
- Vendég: Csak olvasási hozzáférés.
GitHub Actions RBAC példa munkafolyamatra:
Kötelező hozzáférés-vezérlés (MAC)
A kötelező hozzáférés-vezérlés (MAC hozzáférés-vezérlés) szigorú, rendszerszintű szabályokat érvényesít, amelyeket a felhasználók és a rendszergazdák nem bírálhatnak felül. Használja a Mac hozzáférés-vezérlést. hogy szigorúan szabályozza, ki olvashatja, írhatja vagy futtathatja a kritikus erőforrásokat.
Példa: Google Artifact Registry szabályzat (egyszerűsített YAML)
Példa: Amazon ECR szabályzat (egyszerűsített YAML)
A kézi felülbírálás kockázatai és hogyan előzi meg őket a MAC
Az RBAC egyik legnagyobb kockázata DAC modellek fennáll a szándékos vagy véletlenszerű manuális felülbírálások lehetősége. Például egy rendszergazda vagy fejlesztő közvetlenül feltölthet összetevőket egy védett beállításjegyzékbe, vagy a meghatározott hozzáférés-vezérlési szabályzatokon kívül eső túlzott engedélyeket adhat. Ezek a műveletek sebezhetőségeket okozhatnak, vagy megfelelőségi réseket okozhatnak.
A kötelező hozzáférés-vezérlés (MAC hozzáférés-vezérlés) megakadályozza az ilyen felülbírálásokat olyan rendszerszintű szabályzatok kikényszerítésével, amelyeket egyetlen felhasználó, még az adminisztrátorok sem tudnak megkerülni. Hozzáférés decisAz ionokat az infrastruktúrába ágyazott, megváltoztathatatlan szabályok szabályozzák (például felhőalapú IAM-szabályzatok vagy operációsrendszer-szintű biztonsági modulok). Ez azt jelenti, hogy:
- Egy rendszergazda nem tölthet fel manuálisan összetevőket a beállításjegyzékbe, ha a Mac hozzáférés-vezérlési szabályzata ezt megtiltja.
- A felhasználók nem terjeszthetik ki a jogosultságokat, és nem módosíthatják az engedélyeket a meghatározott hozzáférés-vezérlési szabályzatokon kívül.
- Automatizált CI/CD pipelineszigorúan a hozzájuk rendelt engedélyeken belül futnak, megakadályozva a hatókör növekedését.
A manuális felülbírálások kiküszöbölésével a kötelező hozzáférés-vezérlés erősebb és megbízhatóbb biztonsági helyzetet biztosít, mint az RBAC vagy a DAC önmagában.
2.4 Diszkrecionális hozzáférés-vezérlés (DAC)
A DAC lehetővé teszi az erőforrás-tulajdonosok számára, hogy manuálisan adjanak ki jogosultságokat. Rugalmas, de kockázatos. Egyetlen rossz megosztás is veszélyeztetheti a repót. A DAC a következőképpen működik: „A tiéd a tulajdonos, te döntöd el, hogy ki kaphat bele.”
Példa: Egy A fejlesztő meghív egy külső munkatársat, és írási hozzáférést ad neki a repóhoz. A munkatárs közvetlenül a nem biztonságos kódot küldi a dev ág.
In CI/CDA DAC úgy nézhet ki, mintha egy fejlesztő manuálisan adna éles telepítési hozzáférést egy ideiglenes csapattagnak a konzolon keresztül, minden meghatározott hozzáférés-vezérlési szabályzaton kívül.
Hogyan válasszunk olyan hozzáférés-vezérlési szabályzatot, amely a valóságban is működik? Pipelines
Hozzáférés-vezérlés a Gitben
Használja ki az RBAC-t a közreműködői, karbantartói és kiadási szerepkörök kezeléséhez. Zárolja az egyesítési jogokat a védett ágakhoz. Aláírás szükséges. commités korlátozzák, hogy kik kerülhetik meg a védelmeket.
Példa: GitHub ágvédelmi szabályok
- Kötelező pull request felülvizsgálatok az összevonás előtt.
- Elévült üzenet elvetése pull request jóváhagyások, amikor újak commits-t tolnak.
- Aláírás szükséges commits.
- Éles környezetben kritikus adattárak esetén hagyd ki a DAC-ot. Ne adj ki írási hozzáférést véletlenszerűen.
Pipeline Végrehajtás
Kötelező hozzáférés-vezérlés bevezetése pipelines. Egy stabil Mac hozzáférés-vezérlési modell a CI-feladatokat csak a szükséges engedélyekre korlátozza.
- A titkokat környezet szerint különítsd el.
- Használjon egyedi tokeneket környezetenként.
- Akadályozza meg, hogy a manuális futtatások befolyásolják a termelést.
Példa: Egy CI-feladat újra felhasznál egy telepítési tokent a tesztelési és a gyártási környezetben, véletlenül éles állapotba helyezve a tesztkódot.
Mac hozzáférés-vezérlési szabályok hozzáadása a token hatókörének szabályozásához:
Titkok hatókörének meghatározására példa: Környezetspecifikus tokenek használata
A titkok környezet szerinti megfelelő hatókörének meghatározása kritikus fontosságú a következők szempontjából: megakadályozhatja a véletlen vagy rosszindulatú, környezeteken átívelő hozzáférést. Például egy fejlesztői környezethez tartozó telepítési token soha nem használható éles környezetben történő telepítéshez.
Így különítik el a hozzáférés-vezérlési szabályzaton alapuló vezérlők a titkos használatot a GitHub Actionsben:
Ez kikényszeríti, hogy:
- Csak a fejlesztő szerepkör a fejlesztői token használatával indíthat el telepítéseket a dev ág.
- Csak a kiadáskezelő a szerepkör éles környezetben telepíthető a termék token használatával a fő- ág.
Az ilyen hatókörön belüli titkos használat csökkenti a tokenszivárgások kockázatát a környezetek között, és a legkisebb privilégiumokat érvényesíti CI/CD pipelines szigorú hozzáférés-vezérlési szabályzatok betartása.
Műtárgyhozzáférés-vezérlés
Zárolja az artefaktum-nyilvántartásokat kötelező hozzáférés-vezérléssel. CI/CD A rendszereknek kell kezelniük a közzétételt, nem az egyes fejlesztőknek.
Az RBAC használatával meghatározhatja, hogy mely csapatok kérhetnek le adatokat adott beállításjegyzékekből. A fejlesztőknek esetleg csak olvasási hozzáférésre van szükségük az éles csomagokhoz.
Gyakori hozzáférés-vezérlési hibák a fejlesztői munkafolyamatokban
Túlzottan engedékeny repóhozzáférés
Probléma: Túl sok felhasználónak ad írási/adminisztrátori hozzáférést a repókhoz.
Hogyan történik: A csapattagokat előléptetik vagy hozzáadják a jogosultságok felülvizsgálata nélkül. A szerepkörök túlméretezetté válnak.
Támadó kihasználása: A támadók ellopott hitelesítő adatokkal vagy pszichológiai manipulációval célozzák meg ezeket a fiókokat. Ha már bejutottak, rosszindulatú kódot vagy hátsó ajtókat juttathatnak be, vagy eltávolíthatják az előzményeket a nyomok elrejtése érdekében.
Megosztott jogosultságok a fejlesztő és a gyártó között
Probléma: Fejlesztői és produceri feladatok ellátása pipelinemegosztási engedélyek.
Hogyan történik: A csapatok ugyanazt a telepítési tokent vagy CI-szolgáltatásfiókot használják újra a különböző környezetekben.
Támadó kihasználása: Egy fejlesztői környezetbe való betörés éles hozzáférést biztosít a támadóknak. Kötelező hozzáférés-vezérlés Ezt megakadályozhatja azáltal, hogy az engedélyeket adott környezetekhez köti.
Manuális műtermék-feltöltések
Probléma: Lehetővé teszi a manuális összetevők feltöltését az éles rendszerleíró adatbázisokba.
Hogyan történik: Fejlesztők megkerülik pipelinegyors megoldásokhoz vagy forró foltokhoz.
Támadó kihasználása: A feltört fejlesztői gépek közvetlenül a műtermék-tárolóba tölthetnek fel rosszindulatú programokat, megkerülve mindent CI/CD biztonsági ellenőrzések.
A nyilvántartási szabályzattal való visszaélés kockázata: Az összetevők manuális közzététele kritikus támadási felületet teremt a szoftverellátási láncban. A támadók kihasználhatják a lazaságot hozzáférés-szabályozási szabályzatok rosszindulatú kódot juttathat be megbízható csomagokba vagy konténerképekbe, ami széles körű downstream kompromittáláshoz vezethet. A szoftverellátási láncban történt legutóbbi incidensek megmutatták, hogy a szabályozatlan műtermékek feltöltése hogyan fajulhat gyorsan súlyos biztonsági réssé, számtalan felhasználót és rendszert érintve.
Példa: egyEgy teljes npm rendszerleíró adatbázis-hozzáféréssel rendelkező gyakornok véletlenül instabil verziót tesz közzé. Ha egy támadó feltörte volna a gyakornok gépét, akkor kártevőt is közzétehetett volna.
Gyakorlati lépések a szigorú hozzáférés-vezérlés érvényesítéséhez
- Rendelje hozzá a szerepköröket pontos jogosultságokhoz, és szabaduljon meg az egyetlen szerepkört alkalmazó beállításoktól
- Automatizálja a hozzáférés-vezérlési szabályzatok ellenőrzését a rendszerében CI/CD pipelines
- Regisztrációk zárolása kötelező hozzáférés-vezérléssel
- A kritikus rendszerekhez való hozzáférés folyamatos naplózása és monitorozása
- A hozzáférés-vezérlési szabályzatokat úgy kezeljük, mint a kódot. Minden hibát ki lehet használni.
Xygeni szerepe: Hozzáférési szabályzatok betartatása és monitorozása DevOps munkafolyamatokban
Xygeni Segítségével a kötelező hozzáférés-vezérlést az elméletből a gyakorlatba ültetheti azáltal, hogy valós, mindennapi hozzáférés-vezérlési szabályzat-végrehajtási kihívásokat old meg a DevSecOps rendszerben. pipelines.
- A túlzottan engedélyezett Git-hozzáférés megoldása: A Xygeni folyamatosan figyeli a Git-tárházakat az RBAC-szabálysértések, például a felül nem ellenőrzött szerepkör-hozzárendelések vagy a hiányzó ágvédelmek szempontjából. Riasztást küld, ha a hozzáférés-vezérlési szabályzatok eltérnek a meghatározott szabályoktól, és korrekciós intézkedéseket hajt végre a véletlen összevonások vagy a rosszindulatú PR-ek elkerülése érdekében.
- Lezárás CI/CD Pipelines: A CI-feladatok néha a tervezettnél szélesebb hatókörrel futnak. A Xygeni észleli, ha CI/CD a feladatok a hozzárendelt szerepköreiken túllépő kéréseket vagy műveleteket hajtanak végre, valós időben azonosítva a hatókör-túllépéseket és a jogosultságokkal való visszaéléseket. Ez segít a MAC hozzáférés-vezérlési elvek érvényesítésében a belső rendszereken belül. pipelinea hozzáférést szigorúan a munkakör identitásához és céljához kötve.
- Eredeti elemek közzétételének ellenőrzésének érvényesítése: Ha a fejlesztők továbbra is manuálisan töltenek fel műtermékeket vagy képeket, a Xygeni véget vet ennek. Regisztrációs szintű kötelező hozzáférés-vezérlést alkalmaz, így csak az ellenőrzött... pipeline Az identitások közzétehetnek műtermékeket. Nincs többé emberi feltöltés az éles rendszerleíró adatbázisokba.
- Hozzáférés monitorozása és anomáliák jelzése: A Xygeni segítségével betekintést nyerhet abba, hogy ki, mikor és hogyan fért hozzá. Folyamatosan nyomon követi a titkos kulcsok használatát, a tárházhoz való hozzáférést és a beállításjegyzékbeli interakciókat a szokatlan viselkedés észlelése, a hibás konfigurációk megjelölése és az incidens utáni elemzés segítése érdekében.
Alsó sor: A Xygeni automatizálást és betartatást biztosít a hozzáférés-vezérlési szabályzatok terén, így DevOps környezete biztonságos maradhat anélkül, hogy lelassítaná Önt.
Tehát a hozzáférés-vezérlést úgy kezeljük, mint Code Security
Bárki, akinek telepítési jogosultsága vagy infrastrukturális hozzáférése van, véletlenül vagy sem, feltörheti az alkalmazásodat. Ezért egy kőkemény hozzáférés-vezérlési szabályzat nem opcionális. RBAC használatával megfelelően delegálhatja a szerepköröket. Alkalmazzon kötelező hozzáférés-vezérlést a kritikus rendszerekre. Éles útvonalak esetén hagyja ki teljesen a DAC-ot. Hozzáférés-vezérlési szabályzatok beépítése a rendszerbe DevSecOps ajánlott gyakorlatok. Automatizáld őket. Figyeld őket. Érvényesítsd őket.
TL, DREgy jól érvényesített hozzáférés-vezérlési szabályzat automatikusan biztonságosabbá teszi a kódbázist, a műtermékeket és az infrastruktúrát.
