Javaslatok a fejlesztési életciklus biztonságossá tételéhez

  • Cikk

Az Azure Well-Architected Framework biztonsági ellenőrzőlistájára vonatkozó javaslatra vonatkozik:

SE:02 Biztonságos fejlesztési életciklus fenntartása egy megkeményített, többnyire automatizált és naplózható szoftver ellátási lánc használatával. Biztonságos kialakítást építhet be fenyegetésmodellezéssel a biztonságot legyőző implementációk elleni védelem érdekében.

Kapcsolódó útmutató: Fenyegetéselemzés

Ez az útmutató a kód, a fejlesztési környezet és a szoftver ellátási láncának megerősítésére vonatkozó javaslatokat ismerteti a biztonsági ajánlott eljárások alkalmazásával a fejlesztési ciklus során. Az útmutató megértéséhez ismernie kell a DevSecOpsot.

A biztonsági ciklus diagramja.

A DevSecOps a következőkkel integrálja a biztonságot a DevOps-folyamatokba:

  • A biztonsági tesztelés és ellenőrzés automatizálása.

  • Olyan eszközök implementálása, mint a biztonsági folyamatok a kód és az infrastruktúra kódként (IaC) való vizsgálatához a biztonsági rések kereséséhez.

A számítási feladat középpontjában az üzleti logikát megvalósító alkalmazáskód áll. A kódnak és a kód létrehozásának folyamatának biztonsági hibáktól mentesnek kell lennie a titkosság, az integritás és a rendelkezésre állás biztosítása érdekében.

Nem elég, ha csak az infrastruktúra síkját védi az identitás- és hálózatkezelési vezérlők és egyéb intézkedések használatával. A kód rossz implementációjának vagy egy feltört kódblokknak a megakadályozása az általános biztonsági helyzet megerősítéséhez. A használati síkot, azaz az alkalmazáskódot is meg kell edzeni. A biztonság fejlesztési életciklusba való integrálásának folyamata lényegében egy megkeményítő folyamat. Az erőforrások megerősítéséhez hasonlóan a kódfejlesztés szigorítása is környezetfüggő. A hangsúly a biztonság fokozásán van, nem pedig az alkalmazás funkcionális követelményein. A megerősítéssel kapcsolatos információkért lásd: Javaslatok az erőforrások megerősítéséhez.

Definíciók

Időszak Definíció
Biztonságfejlesztési életciklus (Security Development Lifecycle, SDL) A Microsoft által biztosított olyan gyakorlatok, amelyek támogatják a biztonsági garanciára és a megfelelőségi követelményekre vonatkozó követelményeket.
Szoftverfejlesztési életciklus (SDLC) A szoftverrendszerek fejlesztésének többlépcsős, szisztematikus folyamata.

Kulcsfontosságú tervezési stratégiák

A biztonsági intézkedéseket több ponton kell integrálni a meglévő szoftverfejlesztési életciklusba (SDLC), hogy biztosítsa a következőket:

  • A tervezési döntések nem vezetnek biztonsági résekhez.

  • Az alkalmazáskód és a konfiguráció nem hoz létre biztonsági réseket a kihasználható implementáció és a nem megfelelő kódolási eljárások miatt.

  • Az ellátási láncon keresztül beszerzett szoftverek nem jelentenek biztonsági fenyegetéseket.

  • Az alkalmazáskód- és buildelési és üzembehelyezési folyamatokat nem módosítja a rendszer.

  • Az incidensek által feltárt biztonsági rések mérséklődnek.

  • A fel nem használt eszközök megfelelően leszerelhetők.

  • A megfelelőségi követelmények nem sérülnek vagy csökkennek.

  • A naplózás fejlesztői környezetekben van implementálva.

A következő szakaszok biztonsági stratégiákat nyújtanak az SDLC általánosan alkalmazott fázisaihoz.

Követelmények fázisa

A követelmények fázisának célja, hogy összegyűjtse és elemezze egy alkalmazás vagy egy alkalmazás új funkciójának funkcionális és nem funkcionális követelményeit. Ez a fázis azért fontos, mert megkönnyíti az alkalmazás célkitűzéseihez igazított védőkorlátok létrehozását. Az adatok és az alkalmazás integritásának védelme alapvető követelmény a fejlesztési életciklus minden fázisában.

Vegyünk például egy olyan alkalmazást, amely támogatnia kell a kritikus felhasználói folyamatokat, amelyek lehetővé teszik a felhasználó számára az adatok feltöltését és kezelésére. A biztonsági kialakítási lehetőségeknek ki kell terjedniük a felhasználó alkalmazással való interakciójára vonatkozó biztosítékokra, például a felhasználói identitás hitelesítésére és engedélyezésére, csak az adatokon engedélyezett műveletek engedélyezésére és az SQL-injektálás megakadályozására. Hasonlóképpen, fedje le a nem funkcionális követelményeket, például a rendelkezésre állást, a méretezhetőséget és a karbantarthatóságot. A biztonsági lehetőségek közé tartoznak a szegmentálási határok, a tűzfal bejövő és kimenő forgalma, valamint egyéb, horizontális biztonsági szempontok.

Ezeknek a döntéseknek az alkalmazás biztonsági helyzetének helyes meghatározásához kell vezetniük. Dokumentálja a biztonsági követelményeket egy jóváhagyott specifikációban , és tükrözze azt a hátralékban. Kifejezetten meg kell adnia azokat a biztonsági befektetéseket, kompromisszumokat és kockázatokat, amelyeket a vállalat hajlandó vállalni, ha a befektetéseket nem hagyják jóvá az üzleti érdekelt felek. Dokumentálhatja például, hogy webalkalmazási tűzfalat (WAF) kell használnia az alkalmazás előtt, például az Azure Front Doort vagy Azure Application Gateway. Ha az üzleti érdekelt felek nem hajlandók elfogadni a WAF futtatásának további költségeit, el kell fogadniuk annak kockázatát, hogy az alkalmazásrétegbeli támadások az alkalmazás felé irányulhatnak.

A biztonsági követelmények összegyűjtése a fázis kritikus része. E nélkül a tervezési és megvalósítási fázisok instabil döntéseken alapulnak, ami biztonsági hiányosságokhoz vezethet. Előfordulhat, hogy később módosítania kell az implementációt a biztonság érdekében, ami költséges lehet.

Tervezési fázis

Ebben a fázisban a biztonsági követelmények technikai követelményekké alakulnak. A műszaki specifikációban dokumentáljon minden tervezési döntést, hogy megakadályozza a kétértelműséget a megvalósítás során. Íme néhány tipikus feladat:

A rendszerarchitektúra biztonsági dimenziójának meghatározása

Az architektúra átfedése biztonsági vezérlőkkel. Ilyenek például a szegmentálási stratégia szerinti elkülönítési határokra, az alkalmazás összetevőihez szükséges identitástípusokra és a használandó titkosítási módszerek típusára vonatkozó vezérlők. Néhány példaarchitektúra esetében tekintse meg az Identitás- és hozzáférés-kezelés és hálózatkezelés című cikkek Példa szakaszaiban található ábrákat.

A platform által biztosított megfizethetőség értékelése

Fontos megérteni az Ön és a felhőszolgáltató közötti felelősségmegosztást. Kerülje például az Azure natív biztonsági vezérlőivel való átfedést. Jobb biztonsági lefedettséget érhet el, és a fejlesztési erőforrásokat az alkalmazás igényeihez igazíthatja.

Ha például a terv egy webalkalmazási tűzfalat kér a bejövő forgalomhoz, kioszthatja ezt a felelősséget egy terheléselosztónak, például Application Gateway vagy az Azure Front Doornak. Kerülje a szolgáltatások egyéni kódként való replikálását az alkalmazásban.

Csak megbízható keretrendszereket, kódtárakat és ellátásilánc-szoftvereket válasszon. A kialakításnak a biztonságos verziókövetést is meg kell adnia. Az alkalmazásfüggőségeket megbízható felektől kell származnia. A külső szállítóknak képesnek kell lenniük megfelelni az Ön biztonsági követelményeinek , és meg kell osztaniuk a felelős közzétételi tervüket. Minden biztonsági incidenst azonnal jelenteni kell, hogy meg tudja tenni a szükséges műveleteket. Emellett előfordulhat, hogy a szervezet tilt bizonyos kódtárakat. Előfordulhat például, hogy a szoftver biztonságos a biztonsági rések ellen, de a licencelési korlátozások miatt továbbra sem.

Annak érdekében, hogy ezt az útmutatót a szoftver összes közreműködője kövesse, jegyezze fel a jóváhagyott és/vagy nem jóváhagyott keretrendszerek, kódtárak és szállítók listáját. Ha lehetséges, helyezzen védőkorlátokat a fejlesztési folyamatokba a lista támogatásához. A lehető legnagyobb mértékben automatizálja az eszközök használatát a függőségek biztonsági réseinek vizsgálatához.

Határozza meg azokat a biztonsági tervezési mintákat, amelyeket az alkalmazáskódnak implementálnia kell.

A minták támogathatják az olyan biztonsági szempontokat, mint a szegmentálás és az elkülönítés, az erős engedélyezés, az egységes alkalmazásbiztonság és a modern protokollok. Egyes működési minták, például a Karantén minta segíthetnek ellenőrizni és letiltani az olyan szoftverek használatát, amelyek biztonsági réseket okozhatnak.

További információ: A biztonságot támogató felhőtervezési minták.

Alkalmazáskulcsok biztonságos tárolása

Biztonságosan implementálhatja az alkalmazás által használt titkos alkalmazáskulcsok és előre megosztott kulcsok használatát. A hitelesítő adatokat és az alkalmazáskulcsokat soha nem szabad a forráskódfán tárolni. Külső erőforrások, például az Azure Key Vault használatával biztosíthatja, hogy ha a forráskód elérhetővé válik egy potenciális támadó számára, ne lehessen további hozzáférést szerezni. Általánosságban elmondható, hogy megtalálja a titkos kódok elkerülésének módját. Ha lehetséges, a felügyelt identitások használata az egyik módja ennek a célnak. További információ: Javaslatok az alkalmazás titkos kulcsainak kezeléséhez.

Teszttervek meghatározása

Egyértelmű tesztelési esetek definiálása a biztonsági követelményekhez. Értékelje ki, hogy automatizálhatja-e ezeket a teszteket a folyamatokban. Ha a csapata rendelkezik manuális tesztelési folyamatokkal, adja meg a tesztek biztonsági követelményeit.

Megjegyzés

Ebben a fázisban végezzen fenyegetésmodellezést. A fenyegetésmodellezéssel meggyőződhet arról, hogy a tervezési döntések megfelelnek a biztonsági követelményeknek, és elérhetővé teszik azokat a hiányosságokat, amelyeket érdemes enyhíteni. Ha a számítási feladat rendkívül érzékeny adatokat kezel, olyan biztonsági szakértőket is be kell fektetnie, akik segíthetnek a fenyegetésmodellezés végrehajtásában.

A kezdeti fenyegetésmodellezési gyakorlatnak a tervezési fázisban kell történnie, amikor a szoftver architektúrája és magas szintű kialakítása meg van határozva. Ebben a fázisban segít azonosítani a potenciális biztonsági problémákat, mielőtt azok beépülnének a rendszer struktúrájába. Ez a gyakorlat azonban nem egyszeri tevékenység. Ez egy folyamatos folyamat, amely a szoftver fejlődése során folytatódik.

További információ: Javaslatok fenyegetéselemzéshez.

Fejlesztési és tesztelési fázis

Ebben a fázisban a cél a biztonsági hibák megelőzése és a kód-, buildelési és üzembehelyezési folyamatok illetéktelen illetéktelen használata.

Jól betanított a biztonságos kódokkal kapcsolatos eljárásokban

A fejlesztői csapatnak formális és speciális képzéssel kell rendelkeznie a biztonságos kódolási gyakorlatok terén. Előfordulhat például, hogy a webes és API-fejlesztőknek speciális képzésre van szükségük a webhelyek közötti szkriptelési támadások elleni védelemhez, a háttérfejlesztők pedig részletes betanítással elkerülhetik az adatbázisszintű támadásokat, például az SQL-injektálási támadásokat.

A fejlesztőknek el kell végezniük ezt a képzést, mielőtt hozzáférhetnének az éles forráskódhoz.

A folyamatos tanulás elősegítése érdekében belső társkód-felülvizsgálatokat is végre kell hajtania.

Biztonsági teszteszközök használata

Végezzen fenyegetésmodellezést az alkalmazás architektúrájának biztonságának kiértékeléséhez.

Használjon statikus alkalmazásbiztonsági tesztelést (SAST) a biztonsági rések kódjának elemzéséhez. Integrálja ezt a módszertant a fejlesztői környezetbe a biztonsági rések valós idejű észleléséhez.

Használjon dinamikus alkalmazásbiztonsági tesztelést (DAST) futtatókörnyezetben. Ez az eszközlánc képes hibákat keresni a biztonsági tartományokban, és szimulálni egy támadáskészletet az alkalmazás biztonsági rugalmasságának teszteléséhez. Ha lehetséges, integrálja ezt az eszközt a buildfolyamatokba.

Kövesse az iparági szabványokat a biztonságos kódolási eljárásokhoz. További információt a cikk Közösségi források című szakaszában talál.

Használjon lintereket és kódelemzőket a hitelesítő adatok forráskód-adattárba való leküldésének megakadályozásához. A .NET Compiler Platform (Roslyn) elemzői például ellenőrzik az alkalmazás kódját.

A buildelési folyamat során folyamat-bővítmények használatával kapja meg a hitelesítő adatokat a forráskódban. A folyamatos integrációs folyamat részeként tekintse át az összes függőséget, például a külső kódtárakat és a keretrendszer összetevőit. Vizsgálja meg az eszköz által megjelölt sebezhető összetevőket. Kombinálja ezt a feladatot más kódvizsgálati feladatokkal, amelyek ellenőrzik a kódváltozást, a teszteredményeket és a lefedettséget.

Használjon tesztek kombinációját. A biztonsági tesztelésre vonatkozó általános információkért lásd: Javaslatok biztonsági teszteléshez.

Elég kód írása

Ha csökkenti a kód lábnyomát, a biztonsági hibák esélyét is csökkenti. A kód duplikálása helyett használja újra a már használatban lévő és biztonsági ellenőrzésen áteső kódokat és kódtárakat.

Az Azure funkcióinak kihasználása egy másik módszer a szükségtelen kódok megelőzésére. Ennek egyik módja a felügyelt szolgáltatások használata. További információ: A platformszolgáltatás (PaaS) beállításainak használata.

Alapértelmezés szerint a deny-all megközelítéssel írhat kódot. Csak hozzáféréssel rendelkező entitásokhoz hozzon létre engedélyezési listákat. Ha például olyan kóddal rendelkezik, amely meghatározza, hogy engedélyezni kell-e egy emelt szintű műveletet, meg kell írnia, hogy a megtagadási eredmény legyen az alapértelmezett eset, és az engedélyezési eredmény csak akkor történjen meg, ha a kód kifejezetten engedélyezi.

Fejlesztői környezetek védelme

A fejlesztői munkaállomásokat erős hálózati és identitásvezérlőkkel kell védeni a kitettség elkerülése érdekében. Győződjön meg arról, hogy a biztonsági frissítéseket a rendszer körültekintően alkalmazza.

A fordítóügynökök magas szintű jogosultságokkal rendelkeznek, és hozzáféréssel rendelkeznek a buildkiszolgálóhoz és a kódhoz. Ezeket ugyanolyan szigorúsággal kell védeni, mint a számítási feladat összetevőit. Ez azt jelenti, hogy a buildügynökökhöz való hozzáférést hitelesíteni és engedélyezni kell, hálózati szegmensekre kell bontani tűzfalvezérlőkkel, sebezhetőségi vizsgálatnak kell alávetni őket, és így tovább. A Microsoft által üzemeltetett buildügynököket előnyben kell részesíteni a saját üzemeltetésű buildügynökökkel szemben. A Microsoft által üzemeltetett ügynökök olyan előnyöket biztosítanak, mint a tiszta virtuális gépek a folyamatok minden egyes futtatásához.

Az egyéni buildügynökök összetettebbé tehetik a felügyeletet, és támadási vektorsá válhatnak. A buildelési gép hitelesítő adatait biztonságosan kell tárolni, és rendszeresen el kell távolítania az ideiglenes buildösszetevőket a fájlrendszerből. A hálózatelkülönítést úgy érheti el, hogy csak a buildügynök kimenő forgalmát engedélyezi, mert az az Azure DevOpsszal folytatott kommunikáció lekéréses modelljét használja.

A forráskódtárat is védeni kell . Adjon hozzáférést a kódtárakhoz a szükséges információk alapján, és a támadások elkerülése érdekében a lehető legnagyobb mértékben csökkentse a biztonsági réseknek való kitettséget. Alaposan tekintse át a biztonsági rések kódját. Erre a célra használjon biztonsági csoportokat, és implementáljon egy üzleti indokláson alapuló jóváhagyási folyamatot.

Biztonságos kódtelepítések

Nem elég a kód biztonságossá tételéhez. Ha kihasználható folyamatokban fut, minden biztonsági erőfeszítés hiábavaló és hiányos. A buildelési és kiadási környezeteket is védeni kell , mert meg szeretné akadályozni, hogy a rossz szereplők rosszindulatú kódot futtasson a folyamatban.

Az alkalmazásba integrált összes összetevő naprakész leltárának karbantartása

Az alkalmazásba integrált minden új összetevő növeli a támadási felületet. Az új összetevők hozzáadásakor vagy frissítésekor a megfelelő elszámoltathatóság és riasztás érdekében leltárt kell készítenie ezekről az összetevőkről. Tárolja a buildkörnyezeten kívül. Rendszeresen ellenőrizze, hogy a jegyzékfájl megegyezik-e a buildelési folyamat adataival. Ezzel biztosíthatja, hogy ne legyenek váratlanul a hátsó ajtókat vagy más kártevőket tartalmazó új összetevők.

Folyamattevékenységek

  • Lekérheti a folyamat tevékenységeit megbízható forrásokból, például Azure Marketplace. Futtassa a folyamat szállítója által írt feladatokat. GitHub-feladatokat vagy GitHub Actions javasoljuk. Ha GitHub-munkafolyamatokat használ, a Microsoft által létrehozott feladatokat részesíti előnyben. Emellett ellenőrizze a feladatokat, mert azok a folyamat biztonsági környezetében futnak.

  • Folyamat titkos kódjai. A folyamaton belül futó üzembehelyezési eszközök hozzáférhetnek a folyamat összes titkos kulcsához. A szükségtelen expozíció elkerülése érdekében a folyamat különböző szakaszainak megfelelő szegmentálást kell elvégeznie. Használjon a folyamatba beépített titkos kulcstárakat. Ne feledje, hogy bizonyos helyzetekben elkerülheti a titkos kódok használatát. Megismerheti a számítási feladatok identitásainak (folyamathitelesítéshez) és a felügyelt identitások (szolgáltatások közötti hitelesítéshez) használatát.

A különböző környezetek elkülönítése

A különböző környezetekben használt adatokat külön kell tárolni. Az éles adatokat nem szabad alacsonyabb környezetekben használni , mert előfordulhat, hogy ezek a környezetek nem rendelkeznek az éles környezet szigorú biztonsági vezérlőivel. Kerülje a nem éles alkalmazásokból az éles adatbázishoz való csatlakozást, és kerülje a nem éles összetevők éles hálózatokhoz való csatlakoztatását.

Progresszív expozíció

A felhasználók egy részhalmaza számára a kiválasztott feltételek alapján fokozatosan szabadíthat fel funkciókat . Ha problémák merülnek fel, a hatás minimálisra csökken az érintett felhasználókra nézve. Ez a megközelítés egy gyakori kockázatcsökkentési stratégia, mivel csökkenti a felszínt. Ahogy a funkció kiforrott, és nagyobb bizalommal rendelkezik a biztonsági garanciákban, fokozatosan elérhetővé teheti azt a felhasználók szélesebb körének.

Éles fázis

Az éles fázis az utolsó felelősségteljes lehetőséget mutatja be a biztonsági rések megoldására. Jegyezze fel az éles környezetben kiadott aranylemezképet.

Verziószámozott összetevők megtartása

Őrizze meg az összes üzembe helyezett eszköz és azok verzióinak katalógusát. Ezek az információk hasznosak az incidensek osztályozása, a problémák enyhítése és a rendszer működő állapotba való visszaállítása során. A verziószámozott adategységek összehasonlíthatók a közzétett gyakori biztonsági résekkel és kitettségekkel (CVE) kapcsolatos közleményekkel is. Ezeket az összehasonlításokat automatizálással kell elvégeznie.

Vészhelyzeti javítások

Az automatizált folyamattervnek rugalmasan kell támogatnia a rendszeres és a vészhelyzeti üzembe helyezést is. Ez a rugalmasság fontos a gyors és felelős biztonsági javítások támogatásához.

Egy kiadás általában több jóváhagyási kapuhoz van társítva. Fontolja meg egy vészhelyzeti folyamat létrehozását a biztonsági javítások felgyorsítása érdekében. A folyamat magában foglalhatja a csapatok közötti kommunikációt. A folyamatnak lehetővé kell tennie a gyors visszaállítási és visszaállítási üzembe helyezéseket, amelyek a normál üzembehelyezési életcikluson kívül eső biztonsági javításokat, kritikus hibákat és kódfrissítéseket kezelik.

Megjegyzés

Mindig rangsorolja a biztonsági javításokat a kényelem érdekében. A biztonsági javítások nem vezetnek be regressziót vagy hibát. Ha vészhelyzeti folyamaton keresztül szeretné felgyorsítani a javítást, alaposan gondolja át, hogy mely automatizált tesztek kerülhetők ki. Értékelje ki az egyes tesztek értékét a végrehajtási idő alapján. Az egységtesztek például általában gyorsan befejeződnek. Az integrációs vagy a végpontok közötti tesztek hosszú ideig futtathatók.

Karbantartási fázis

Ennek a fázisnak a célja annak biztosítása, hogy a biztonsági helyzet ne csökkenjen az idő múlásával. Az SDLC egy folyamatos agilis folyamat. Az előző szakaszokban tárgyalt fogalmak erre a fázisra vonatkoznak, mivel a követelmények idővel változnak.

Javításkezelés. A biztonsági javításokkal és frissítésekkel naprakészen tarthatja a szoftvereket, kódtárakat és infrastruktúra-összetevőket.

Folyamatos fejlesztés. A szoftverfejlesztési folyamat biztonságának folyamatos felmérése és javítása a kódértékelések, a visszajelzések, a tanulságok és a változó fenyegetések figyelembevételével.

Elavult vagy már használatban nem lévő örökölt eszközök leszerelése. Ezzel csökkenti az alkalmazás felületét.

A karbantartás incidensjavításokat is tartalmaz. Ha problémákat találnak az éles környezetben, azonnal integrálva kell őket a folyamatba, hogy ne ismétlődjenek meg.

Folyamatosan fejlesztheti biztonságos kódolási gyakorlatát, hogy lépést tartson a fenyegetésekkel.

Azure-beli facilitálás

A Microsoft Security Development Lifecycle (SDL) olyan biztonságos eljárásokat javasol, amelyek alkalmazhatók a fejlesztési életciklusra. További információ: Microsoft Security Development Lifecycle.

A DevOpshoz készült Defender és a SAST-eszközök a GitHub Advanced Security vagy az Azure DevOps részét képezik. Ezek az eszközök segítenek nyomon követni a szervezet biztonsági pontszámát.

Kövesse az alábbi erőforrásokban ismertetett Azure-biztonsági javaslatokat:

Ha hitelesítő adatokat szeretne keresni a forráskódban, fontolja meg az olyan eszközök használatát, mint a GitHub Advanced Security és az OWASP forráskód-elemző eszközei.

Ellenőrizze az alkalmazás bármely nyílt forráskódú kódjának biztonságát. Ezek az ingyenes eszközök és források segíthetnek az értékelésben:

Biztonsági ellenőrzőlista

Tekintse meg a javaslatok teljes készletét.

Biztonsági ellenőrzőlista