DevSecOps-vezérlők

A DevSecOps úgy alkalmazza az innováció biztonságát , hogy a biztonsági folyamatokat és eszközöket integrálja a DevOps fejlesztési folyamatába.

Mivel maga a DevOps egy új szemlélet, amely magas szintű folyamatváltozatokkal rendelkezik, a sikeres DevSecOps a biztonság megértésén és átgondolt integrálásán alapul a fejlesztési folyamatba. A biztonság hozzáadásának a kód, a fejlesztési folyamatok és a számítási feladatot üzemeltető infrastruktúra kis súrlódású változásaival kell kezdődnie. Először a biztonságra gyakorolt legnagyobb pozitív hatással járó változásokra összpontosítson, miközben a DevOps-folyamatokra és készségekre is nagy terhet ró.

Ez a dokumentáció áttekinti a folyamatos integráció és a folyamatos teljesítés (CI/CD) DevOps-folyamatának minden fázisát, valamint azt, hogy milyen biztonsági vezérlőket javasoljuk először az integráláshoz.

Tervezés és fejlesztés

A modern fejlesztés általában egy agilis fejlesztési módszertant követ. A Scrum az agilis módszertan egyik implementációja, amelynek minden futama egy tervezési tevékenységgel kezdődik. A fejlesztési folyamat ezen részében a biztonság bevezetésének a következőkre kell összpontosítania:

• Fenyegetésmodellezés az alkalmazás megtekintéséhez egy potenciális támadó lencséjén keresztül
• IDE biztonsági beépülő modulok és elő véglegesítési horgok az integrált fejlesztési környezet (IDE) egyszerűsített statikus elemzési ellenőrzéséhez.
• Peer reviews and secure coding standards to identify effective security coding standards, peer review processes, and pre-commit hooks.

Ezeket a lépéseket nem kötelező hozzáadni. Azonban minden lépés segít a biztonsági problémák korai feltárásában, amikor sokkal olcsóbbak és könnyebben megoldhatók.

Fenyegetésmodellezés

A fenyegetésmodellezés vitathatatlanul a legfontosabb biztonsági gyakorlat. Azonnali eredményeket nyújt, és segít biztonsági gondolkodásmód kialakításában a fejlesztők számára, hogy minden jövőbeli projektjük biztonsága javuljon.

A fenyegetésmodellezés egy egyszerű fogalom, de szükség esetén részletes és technikai jellegű is lehet. A fenyegetésmodellezés az alkalmazás reális biztonsági nézetét jeleníti meg és dokumentálja, amely az alábbiakat tartalmazza:

• Hogyan használhatják vissza a támadók az alkalmazás tervét?
• Biztonsági rések javítása
• Mennyire fontos a problémák megoldása

A fenyegetésmodellezés hatékonyan teszi lehetővé a támadók gondolkodásmódját. Lehetővé teszi az alkalmazás megtekintését egy támadó szemével. Megtudhatja, hogyan tilthatja le a kísérleteket, mielőtt a támadók bármit meg tudnak tenni. Ha a csapatnak felhasználói személyisége van a kialakításban, a támadót ellenséges felhasználói személyként kezelheti.

A fenyegetésmodellezéshez közzétett megközelítések az egyszerű kérdés- és válaszmódszerektől a részletes eszközalapú elemzésig terjednek. Megközelítését olyan módszerekre alapozhatja, mint a STRIDE-modell vagy az OWASP fenyegetésmodellezés.

Fenyegetésmodellezés: Egyszerű indítás

Mivel a fenyegetésmodellezés egyes megközelítései időigényesek és készségigényesek lehetnek, javasoljuk, hogy alapszintű kérdéseket használva kezdjen egyszerűbb megközelítéssel. Az egyszerűbb módszerek nem olyan alaposak, de elindítják a kritikus gondolkodási folyamatot, és segítenek gyorsan azonosítani a főbb biztonsági problémákat.

Az alábbi egyszerű kérdések módszerével kezdheti meg az első lépéseket:

• Egyszerű kérdések módszere a Microsofttól: Ez a módszer konkrét technikai kérdéseket tesz fel, amelyek célja a gyakori biztonsági tervezési hibák felszínre hozása.
• OWASP fenyegetésmodellezés: Ez a módszer egyszerű, nem technikai kérdéseket tesz fel a fenyegetésmodellezési folyamat elindításához.

Az alábbi módszerek egyikét vagy mindkettőt használhatja attól függően, hogy mi működik jobban a csapat számára.

Ha csapata jobban ismeri a folyamatot, a Microsoft biztonsági fejlesztési életciklusából fejlettebb technikákat alkalmazhatnak. Emellett integrálhatják a fenyegetésmodellezési eszközöket, például a Microsoft fenyegetésmodellező eszközét , hogy mélyebb betekintést nyerjenek, és segítsenek automatizálni a folyamatot.

Egy másik hasznos forrás a fejlesztők fenyegetésmodellezésének útmutatója.

IDE biztonsági beépülő modulok és elő véglegesítési horgok

A fejlesztők a teljesítés sebességére összpontosítanak, és a biztonsági vezérlők lelassíthatják a folyamatot. A lassulás általában akkor fordul elő, ha a biztonsági ellenőrzések a folyamatnál kezdődnek. A fejlesztő a kód adattárba való leküldése után rájön a lehetséges biztonsági résre. A folyamat felgyorsítása és az azonnali visszajelzés érdekében érdemes olyan lépéseket hozzáadni, mint az IDE biztonsági beépülő modulok és a horgok előzetes véglegesítése.

Az integrált fejlesztési környezet (IDE) biztonsági beépülő moduljai különböző biztonsági problémákat azonosítanak a fejlesztési folyamat során a fejlesztő jól ismert IDE-környezetében. A beépülő modulok azonnali visszajelzést adhatnak, ha a fejlesztő írott kódjában potenciális biztonsági kockázat áll fenn. A beépülő modulok kockázatokat is felfedhetnek a külső tárban vagy csomagban. A választott IDE-től függően számos nyílt forráskódú vagy kereskedelmi beépülő modul érhető el, amelyeket a biztonsági vállalatok biztosítanak.

Egy másik lehetőség a véglegesítés előtti keretrendszer használata, ha a verziókövetési rendszer engedélyezi. Az előzetes véglegesítési keretrendszer githoszkripteket biztosít, amelyek segítenek azonosítani a problémákat, mielőtt a fejlesztő kódot küld a kód áttekintéséhez. Ilyen például az előzetes véglegesítés , amelyet a GitHubon állíthat be.

Társviszony-felülvizsgálat és biztonságos kódolási szabványok

A lekéréses kérelmek szabványosak a fejlesztési folyamatban. A lekéréses kérelmek folyamatának része a társértékelések, amelyek gyakran feltáratlan hibákat, hibákat vagy emberi hibákkal kapcsolatos problémákat fednek fel. A lekéréses kérelem létrehozása előtt célszerű olyan biztonsági bajnokot vagy hozzáértő biztonsági csapattagot alkalmazni, aki végigvezetheti a fejlesztőt a társértékelési folyamat során.

A biztonságos kódolási gyakorlat irányelvei segítenek a fejlesztőknek elsajátítani az alapvető biztonságos kódolási alapelveket és azok alkalmazását. Léteznek olyan biztonságos kódolási eljárások, mint például az OWASP biztonságos kódolási eljárásai , amelyeket az általános kódolási eljárásokkal lehet beépíteni.

A kód véglegesítése

A fejlesztők általában olyan adattárakban hozzák létre, kezelik és osztják meg kódjukat, mint a GitHub vagy az Azure Repos. Ez a megközelítés egy központi, verzió által szabályozott kódtárat biztosít a fejlesztőknek a könnyű együttműködéshez. Ha azonban számos közreműködőt engedélyez egy kódbázison, az a módosítások bevezetésének kockázatát is fennállja. Ez a kockázat biztonsági résekhez vezethet, vagy akaratlanul is tartalmazhat hitelesítő adatokat vagy jogkivonatokat a véglegesítésekben.

A kockázat kezelése érdekében a fejlesztői csapatoknak értékelnie kell és végre kell hajtaniuk egy adattár-ellenőrzési képességet. Az adattár-ellenőrző eszközök statikus kódelemzést végeznek a forráskódon az adattárakban. Az eszközök biztonsági réseket vagy hitelesítő adatokat keresnek, és megjelölik a javításra talált elemeket. Ez a képesség védelmet nyújt az emberi hibák ellen, és hasznos védelmet nyújt olyan elosztott csapatok számára, amelyekben sokan dolgoznak együtt ugyanabban az adattárban.

Függőségkezelés

Az aktuális alkalmazásokban a kód akár 90%-a tartalmaz külső csomagok és kódtárak elemeit, vagy ezeken alapul. A függőségek forráskódban való bevezetése elengedhetetlen a lehetséges kockázatok kezeléséhez. Számos külső kódtárnak komoly biztonsági problémái vannak. Emellett a fejlesztők nem következetesen követik a legjobb életciklust, és naprakészen tartják a függőségeket.

Győződjön meg arról, hogy a fejlesztői csapat tudja, milyen összetevőket kell tartalmaznia az alkalmazásaikban. Biztonságos és naprakész verziókat szeretnének letölteni ismert forrásokból. A verziók naprakészen tartásához pedig egy folyamatot szeretnének. A csapat olyan eszközöket használhat, mint az OWASP Dependency-Check projekt, a WhiteSource és mások.

Ha csak a függőségi sebezhetőségekre vagy azok életciklusára szeretne összpontosítani, az nem elég. Fontos a csomagcsatornák biztonságának kezelése is. Vannak ismert támadási vektorok, amelyek csomagkezelési rendszereket céloznak meg: elírás, meglévő csomagok veszélyeztetése, helyettesítési támadások és mások. A felelős csomagkezelési felügyeletnek tehát foglalkoznia kell ezekkel a kockázatokkal. További információ: Három módszer a magáncsomag-hírcsatornák használata kockázatának csökkentésére.

Statikus alkalmazás biztonsági tesztelése

Miután a csapat harmadik féltől származó kódtárakat és csomagkezelést kezel, elengedhetetlen a fókusz áthelyezése és a kódbiztonság javítása. A kódbiztonságot többféleképpen is javíthatja. IDE biztonsági beépülő modulokat is használhat. Vagy elvégezheti a növekményes statikus elemzések véglegesítés előtti és véglegesítési ellenőrzését is, ahogy azt korábban már említettem. Teljes forráskódvizsgálatot is végezhet az előző lépések által kihagyott hibák észlelése érdekében. Ez szükséges, de akár órákat vagy akár napokat is igénybe vehet egy nagy kódblokk beolvasása. Ez a megközelítés tehát lelassíthatja a fejlesztést, és terhet róhat terhet.

A csapatnak azonban valahol el kell indulnia a statikus kódvizsgálati eljárások megvalósításakor. Ennek egyik módja a statikus kódelemzés bevezetése a folyamatos integráción belül. Ez a módszer ellenőrzi a biztonságot, amint a kódmódosítások történnek. Ilyen például a SonarCloud. Több statikus alkalmazásbiztonsági teszteszközt (SAST) csomagol a különböző nyelvekhez. A SonarCloud felméri és nyomon követi a műszaki adósságot, és a fenntarthatóságra összpontosít. Megvizsgálja a kód minőségét és stílusát, és biztonsági ellenőrzőkkel rendelkezik. De számos más kereskedelmi és nyílt forráskódú eszköz áll rendelkezésre a piacon.

Annak érdekében, hogy a visszajelzési ciklus hatékony legyen, elengedhetetlen az eszköz finomhangolása. Minimálisra szeretné csökkenteni a hamis pozitív értékeket, és egyértelmű, végrehajtható visszajelzést szeretne adni a kijavítandó problémákról. Emellett érdemes implementálni egy munkafolyamatot is, amely megakadályozza a kód véglegesítését az alapértelmezett ágra, ha vannak eredmények. A minőséggel és a biztonsági megállapításokkal is foglalkoznia kell. A biztonság tehát az egységtesztelés részévé válik.

Biztonságos folyamatok

A DevOps egy másik szintre emeli az automatizálást, mert a fejlesztési életciklus minden folyamata egy folyamaton megy keresztül. A folyamatos integráció és a folyamatos teljesítés (CI/CD) a modern fejlesztési ciklusok kulcsfontosságú részét képezi. A CI/CD-ben a csapat rendszeresen egyesíti a fejlesztői kódot egy központi kódbázissal, és automatikusan szabványos buildeket és tesztelési folyamatokat futtat.

Az infrastruktúra-folyamatok a fejlesztés központi részét képezik. Ha azonban folyamatokat használ szkriptek futtatására vagy kód éles környezetben való üzembe helyezésére, az egyedi biztonsági problémákat okozhat. Győződjön meg arról, hogy a CI/CD-folyamatok nem válnak rosszindulatú kódok futtatására, hitelesítő adatok ellopására vagy a támadók számára a hozzáféréshez szükséges felületre. Azt is biztosítani szeretné, hogy csak a csapat által kiadni kívánt kód legyen üzembe helyezve.

A DevOps-csapatoknak gondoskodniuk kell arról, hogy a folyamat megfelelő biztonsági vezérlőit implementálják. A választott platformtól függően különböző irányelvek vannak a kockázatok kezelésére vonatkozóan. További információ: Az Azure Pipelines biztonságossá tétele.

Buildelés és tesztelés

Számos szervezet buildelési és kiadási folyamatokat használ a kód létrehozásának és üzembe helyezésének folyamatainak automatizálásához és szabványosításához. A kiadási folyamatok lehetővé teszik, hogy a fejlesztői csapatok gyorsan és nagy léptékben módosítják a kódszakaszokat. A csapatoknak nem kell sok időt fordítaniuk a meglévő környezetek üzembe helyezésére vagy frissítésére.

A kiadási folyamatok használatával a csapatok fejlesztési környezetekből, tesztelési környezetekből és végső soron éles környezetekbe is előléptetik a kódokat. Az automatizálás részeként a fejlesztői csapatoknak olyan biztonsági eszközöket kell tartalmazniuk, amelyek szkriptelt, automatizált teszteket futtatnak a kód tesztelési környezetekben való üzembe helyezésekor. A teszteknek tartalmazniuk kell az alkalmazásfunkciókon végzett egységtesztelést a biztonsági rések vagy nyilvános végpontok ellenőrzéséhez. A tesztelés szándékos hozzáférést biztosít.

Dinamikus alkalmazásbiztonsági tesztelés

A klasszikus vízesésfejlesztési modellben a biztonságot általában az utolsó lépésben vezették be, közvetlenül az éles környezet előtt. Az egyik legnépszerűbb biztonsági módszer a behatolástesztelés vagy a tolltesztelés. A behatolástesztelés lehetővé teszi, hogy a csapat fekete dobozos biztonsági szempontból vizsgálja meg az alkalmazást, ahogyan az a támadói gondolkodásmódhoz legközelebb áll.

A behatolási teszt több műveleti pontból áll, amelyek közül az egyik a dinamikus alkalmazásbiztonsági tesztelés (DAST). A DAST egy webalkalmazás biztonsági tesztje, amely biztonsági problémákat keres a futó alkalmazásban azáltal, hogy megtekinti, hogyan reagál az alkalmazás a speciálisan létrehozott kérelmekre. A DAST-eszközöket webalkalmazási biztonságirés-ellenőrzőknek is nevezik. Ilyen például egy nyílt forráskódú eszköz, az OWASP Zed Attack Proxy (ZAP). Biztonsági réseket talál a futó webalkalmazásban. Az OWASP ZAP-vizsgálatoknak különböző módjai vannak: passzív alapkonfigurációs vizsgálat vagy teljes vizsgálat a konfigurációtól függően.

A tollteszt hátránya, hogy időt vesz igénybe. Egy alapos tollteszt akár több hetet is igénybe vehet, és a DevOps-fejlesztés sebességével ez az időkeret fenntarthatatlan lehet. A SAST és más lépések által kihagyott problémák feltárásához azonban a fejlesztési folyamat során érdemes a tolltesztelés egy világosabb verzióját hozzáadni. Az olyan DAST-eszközök, mint az OWASP ZAP, segíthetnek.

A fejlesztők feladatként integrálják az OWASP ZAP-t a folyamatba. A futtatás során az OWASP ZAP scanner felpörög a tárolóban, és elvégzi a vizsgálatát, majd közzéteszi az eredményeket. Ez a megközelítés talán nem tökéletes, mert nem teljes behatolástesztelés, de még mindig értékes. Ez még egy minőségi intézkedés a fejlesztési ciklusban a biztonsági helyzet javítása érdekében.

Felhőkonfiguráció ellenőrzése és infrastruktúra vizsgálata

Az alkalmazások kódjának vizsgálata és biztonságossá tétele mellett győződjön meg arról, hogy az alkalmazások környezetei is biztonságosak. A biztonságos környezetek kulcsfontosságúak azoknak a szervezeteknek, akik lépést szeretnének tartani, újítani és új technológiákat használni. A biztonságos környezetek abban is segítenek, hogy a csapatok gyorsan új környezeteket hozzanak létre a kísérletezéshez.

Az Azure-képességek lehetővé teszik a szervezetek számára, hogy biztonsági szabványokat hozzanak létre környezetekből, például az Azure Policyból. A Teams az Azure Policy használatával hozhat létre szabályzatkészleteket. A szabályzatkészletek megakadályozzák bizonyos számítási feladatok vagy konfigurációelemek, például nyilvános IP-címek létrehozását. Ezek a védőkorlátok lehetővé teszik a csapatok számára, hogy biztonságos és ellenőrzött környezetben kísérletezhessenek, kiegyensúlyozva az innovációt és a szabályozást.

A DevOps egyik módja, hogy a fejlesztőket és a műveleteket lépésről lépésre egymáshoz igazítsuk, az, hogy támogatjuk a meglévő infrastruktúra kódként való átalakítását.

Az infrastruktúra kódként (IaC) az infrastruktúra (hálózatok, virtuális gépek, terheléselosztók és kapcsolattopológia) kezelése egy leíró modellben. Az IaC ugyanazt a verziószámozási modellt használja, mint a DevOps-csapat a forráskódhoz. Ahogy ugyanazon forráskód elve ugyanazt a bináris fájlt hozza létre, az IaC-modell minden alkalmazáskor ugyanazt a környezetet hozza létre. Az IaC egy kulcsfontosságú DevOps-gyakorlat, amelyet a folyamatos teljesítés során használnak.

A DevSecOps balra tolja a biztonságot, és azt mutatja, hogy a biztonság nem csak az alkalmazásbiztonságról, hanem az infrastruktúra biztonságáról is szól. A DevSecOps egyik módja az infrastruktúra biztonságának támogatása, ha az infrastruktúra felhőben való üzembe helyezése előtt biztonsági vizsgálatot is alkalmaz. Ahogy az infrastruktúra kód lett, ugyanazokat a biztonsági műveleteket kell alkalmaznia az infrastruktúrára, mint az alkalmazásbiztonságra. A kiválasztott IaC-stratégia alapján az infrastruktúra biztonsági vizsgálatának futtatásához rendelkezésre állnak biztonsági eszközök.

A felhő bevezetésével a tárolók használata népszerű megközelítés, amelyet a csapatok az alkalmazásarchitektúra-döntések során hoznak. A tárolótárak némelyike képeket keres az ismert biztonsági résekkel rendelkező csomagok elfogásához. Továbbra is fennáll annak a kockázata, hogy egy tároló elavult szoftverrel rendelkezik. Emiatt a kockázat miatt létfontosságú, hogy biztonsági kockázatokat keressünk a tárolóban. Számos nyílt forráskódú és kereskedelmi biztonsági eszköz létezik, amelyek erre a területre irányulnak, és támogatják a CD-folyamat szoros integrációját. A biztonsági eszközök segítségével a csapatok kódként használhatják a DevSecOps infrastruktúrát, és pontosabban megismerhetik a tárolók használatát.

Ugrás az éles környezetbe és üzemeltetés

Amikor a megoldás éles környezetbe kerül, elengedhetetlen a biztonsági állapot felügyeletének és kezelésének folytatása. A folyamat ezen szakaszában ideje a felhőinfrastruktúrára és az általános alkalmazásra összpontosítani.

Konfiguráció és infrastruktúra vizsgálata

A felhőbeli előfizetések és az erőforrás-konfiguráció több előfizetésben való láthatóságához használja az Azure-bérlő biztonsági megoldását az AzSK csapatától.

Az Azure monitorozási és biztonsági képességeket is tartalmaz. Ezek a képességek észlelik és figyelmeztetik azokat a rendellenes eseményeket vagy konfigurációkat, amelyek kivizsgálást és lehetséges szervizelést igényelnek. Az olyan technológiák, mint a Felhőhöz készült Microsoft Defender és a Microsoft Sentinel, olyan belső eszközök, amelyek natív módon integrálhatók az Azure-környezetekbe. Ezek a technológiák kiegészítik a környezet- és kódbiztonsági eszközöket. A technológiák pedig alapos biztonsági monitorozást biztosítanak, hogy a szervezetek gyorsan és biztonságosan kísérletezhessenek és újítsanak.

Behatolás tesztelése

A behatolástesztelés ajánlott eljárás az infrastruktúra vagy az alkalmazáskonfiguráció biztonsági réseinek ellenőrzésére, ami olyan gyengeségeket okozhat, amelyeket a támadók kihasználhatnak.

Számos termék és partner kínál behatolástesztelési szolgáltatásokat. A Microsoft útmutatást nyújt a behatolásteszteléshez az Azure-ban.

A tesztelés általában a következő teszttípusokat fedi le:

• Tesztek a végpontokon a biztonsági rések feltárásához
• A végpontok Fuzz-tesztelése (programhibák keresése hibás bemeneti adatok megadásával)
• Portkeresés a végpontokon

Végrehajtható intelligencia

Az útmutató eszközei és technikái holisztikus biztonsági modellt kínálnak azoknak a szervezeteknek, akik lépést szeretnének tartani, és olyan új technológiákkal szeretnének kísérletezni, amelyek célja az innováció elősegítése. A DevSecOps kulcsfontosságú eleme az adatvezérelt, eseményvezérelt folyamatok. Ezek a folyamatok segítenek a csapatoknak azonosítani, értékelni és reagálni a lehetséges kockázatokra. Számos szervezet úgy dönt, hogy integrálja a riasztásokat és a használati adatokat az INFORMATIKAI szolgáltatásfelügyeleti (ITSM) platformba. A csapat ezután ugyanazt a strukturált munkafolyamatot használhatja a biztonsági eseményekhez, amelyeket más incidensekhez és kérésekhez használnak.

Visszajelzési hurkok

Mindezek a technikák és eszközök lehetővé teszik a csapatok számára, hogy megtalálják és megjelölik azokat a kockázatokat és biztonsági réseket, amelyek kivizsgálást és lehetséges megoldásokat igényelnek. A riasztást kapó vagy a támogatási jegy vizsgálatakor esetlegesen felmerülő problémát észlelő üzemeltetési csapatoknak vissza kell irányítaniuk a fejlesztési csapathoz, hogy megjelölhessék az elemeket felülvizsgálatra. A zökkenőmentes, együttműködésen alapuló visszajelzési ciklus elengedhetetlen a problémák gyors kezeléséhez, és a lehető legkisebbre csökkenti a sebezhetőség kockázatát.

A visszajelzések gyakori mintája, hogy integrálják azt egy fejlesztői munkafelügyeleti rendszerbe, például az Azure DevOpsba vagy a GitHubba. A szervezetek riasztásokat vagy incidenseket csatolhatnak munkaelemekhez a fejlesztők számára a tervezéshez és a műveletekhez. Ez a folyamat hatékony módot biztosít a fejlesztők számára a standard munkafolyamaton belüli problémák megoldására, beleértve a fejlesztést, a tesztelést és a kiadást.