Javaslatok a fejlesztési életciklus biztonságossá tételéhez
Az Azure Well-Architected Framework biztonsági ellenőrzőlistára vonatkozó javaslatra vonatkozik:
| SE:02 | Biztonságos fejlesztési életciklus fenntartása egy edzett, 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 szoftverellátási lánc megkeményí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 DevSecOps a következőkkel integrálja a biztonságot a DevOps-folyamatokba:
A biztonsági tesztelés és az ellenőrzés automatizálása.
Olyan eszközök implementálása, mint a biztonsági folyamatok, amelyek kódként (IaC) ellenőrzik a kód és az infrastruktúra biztonsági réseit.
A számítási feladatok középpontjában az üzleti logikát megvalósító alkalmazáskód áll. A kódnak és a kód fejlesztésének 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 vagy a feltört kódblokk helytelen implementálásának megakadályozása az általános biztonsági helyzet megerősítése érdekében. A használati síkot, vagyis 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ás-megkeményítéshez 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 megkeményítéssel kapcsolatos információkért tekintse meg az erőforrások megkeményítésére vonatkozó javaslatokat.
Meghatározások
| Időszak | Definíció |
|---|---|
| Biztonságfejlesztési életciklus (Security Development Lifecycle, SDL) | A Microsoft által biztosított eljárások, 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) | Többtényezős, szisztematikus folyamat szoftverrendszerek fejlesztéséhez. |
A biztonsági intézkedéseket több ponton kell integrálnia a meglévő szoftverfejlesztési életciklusba (SDLC), hogy biztosítsa a következőket:
A tervezési lehetőségek 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ó megvalósítás é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 a rendszer nem módosítja.
Az incidensek által feltárt biztonsági rések enyhíthetők.
A fel nem használt eszközök megfelelően leszerelhetők.
A megfelelőségi követelmények nem sérülnek vagy nem 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.
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éljaihoz igazított védőkorlátok létrehozását. Az alkalmazás adatainak és integritásának védelme alapvető követelmény a fejlesztési életciklus minden fázisában.
Vegyük például azt az 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ó és az alkalmazás közötti interakcióra vonatkozó garanciákra, például a felhasználói identitás hitelesítésére és engedélyezésére, az adatokon csak engedélyezett műveletek engedélyezésére és az SQL-injektálás megakadályozására. Hasonlóképpen, kiterjed a nem funkcionális követelményekre, például a rendelkezésre állásra, a méretezhetőségre és a karbantarthatóságra. A biztonsági beállításoknak tartalmazniuk kell a szegmentálási határokat, a tűzfal bejövő és kimenő forgalmát, valamint egyéb horizontális biztonsági szempontokat.
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 egyeztetett specifikációban , és tükrözze azt a hátralékban. Kifejezetten meg kell adnia a biztonsági befektetéseket, valamint azokat a kompromisszumokat és kockázatokat, amelyeket a vállalkozás 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-alkalmazás Gatewayt. Ha az üzleti érdekelt felek nem hajlandók elfogadni a WAF futtatásának többletköltségét, el kell fogadniuk azt a kockázatot, hogy az alkalmazásszintű támadások az alkalmazás felé irányulhatnak.
A biztonsági követelmények összegyűjtése kritikus fontosságú része ennek a fázisnak. 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.
A tervezési fázis során a biztonsági követelmények technikai követelményekké alakulnak. A műszaki specifikációban dokumentálja az összes 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:
Az architektúra átfedése biztonsági vezérlőkkel. Ilyenek például a szegmentálási stratégia elkülönítési határait gyakorlatias vezérlők, az alkalmazás összetevőihez szükséges identitástípusok és a használandó titkosítási módszerek típusa. 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.
Fontos tisztában lenni az Ön és a felhőszolgáltató közötti felelősség megosztásával. Kerülje például az átfedést az Azure natív biztonsági vezérlőivel. 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 tervezés egy webalkalmazási tűzfalat hív meg bejövő forgalom esetén, ezt a felelősséget kioszthatja egy terheléselosztóra, például az Application Gatewayre vagy az Azure Front Doorra. Kerülje a funkciók 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 tervnek biztonságos verziókövetést is meg kell adnia. Az alkalmazásfüggőségeket megbízható felektől kell beszerezni. A külső gyártóknak meg kell felelniük a biztonsági követelményeknek , é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 licenckorlátozások miatt továbbra sem engedélyezett.
Annak érdekében, hogy ezt az útmutatást a szoftver összes közreműködője kövesse, őrizze meg 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.
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ókért tekintse meg a biztonságot támogató felhőtervezési mintákat.
Biztonságosan implementálhatja az alkalmazás által használt alkalmazáskulcsok és előre megosztott kulcsok használatát. A hitelesítő adatokat és az alkalmazás titkos kulcsait soha nem szabad a forráskódfában tárolni. Az Azure Key Vaulthoz hasonló külső erőforrások 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ában keresse meg a titkos kódok elkerülésének módját. A cél elérésének egyik módja a felügyelt identitások használata, ha lehetséges. További információ: Javaslatok az alkalmazás titkos kulcsainak kezeléséhez.
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 csapat manuális tesztelési folyamatokkal rendelkezik, a tesztekkel kapcsolatos biztonsági követelményeket is tartalmaznia kell.
Megjegyzés
Ebben a fázisban végezze el a fenyegetésmodellezést. A fenyegetésmodellezéssel meggyőződhet arról, hogy a tervezési lehetőségek megfelelnek a biztonsági követelményeknek, és elérhetővé teszik a mérsékelendő hiányosságokat. Ha a számítási feladatok rendkívül bizalmas adatokat kezelnek, olyan biztonsági szakértőkbe kell befektetnie, akik segíthetnek a fenyegetésmodellezésben.
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 lehetséges 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 a fenyegetéselemzéshez.
A fejlesztési és tesztelési fázisban a cél a biztonsági hibák megelőzése és a kód- és buildelési és üzembehelyezési folyamatok illetéktelen beavatkozása.
A fejlesztői csapatnak formális és speciális képzéssel kell rendelkeznie a biztonságos kódolási eljárások terén. Előfordulhat például, hogy a web- és API-fejlesztőknek speciális képzésre van szükségük a helyek közötti szkriptelési támadások elleni védelemhez, a háttérfejlesztők pedig alapos 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érné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.
Fenyegetésmodellezés végrehajtása 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) futásidőben. Ez az eszközlánc képes ellenőrizni a biztonsági tartományok hibáit, é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 buildelési folyamatokba.
Kövesse az iparági szabványokat a biztonságos kódolási eljárásokhoz. További információkért tekintse meg a cikk Közösségi erőforrások szakaszát.
Használjon lintereket és kódelemzőket a hitelesítő adatok forráskódtárba való leküldésének megakadályozásához. A .NET Fordító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 forráskódban szereplő hitelesítő adatokat. A folyamatos integrációs folyamat részeként vizsgálja meg az összes függőséget, például a külső kódtárakat és a keretrendszer-összetevőket. Vizsgálja meg az eszköz által megjelölt sebezhető összetevőket. Kombinálja ezt a feladatot más kódolvasási feladatokkal, amelyek a kódváltozást, a teszteredményeket és a lefedettséget vizsgálják.
Használjon tesztek kombinációját. A biztonsági tesztelésre vonatkozó általános információkért tekintse meg a biztonsági tesztelésre vonatkozó ajánlásokat.
A kód lábnyomának csökkentésekor a biztonsági hibák esélye is csökken. A már használatban lévő és biztonsági ellenőrzésen áteső kódokat és kódtárakat használja újra a kód duplikálása helyett.
Az Azure-funkciók előnyeinek 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ó: Platform használata szolgáltatásként (PaaS).
A kódot alapértelmezés szerint megtagadási módszerrel kell írnia. 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 kiemelt műveletet, akkor azt úgy 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.
A fejlesztői munkaállomásokat erős hálózati és identitásvezérlőkkel kell védeni az expozíció megelőzése érdekében. Győződjön meg arról, hogy a biztonsági frissítéseket gondosan alkalmazza a rendszer.
A buildügynökök kiemelt 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, tűzfalvezérlőkkel kell hálózatszegmensbe helyezni őket, 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 nyújtanak, 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épek hitelesítő adatait biztonságosan kell tárolni, és rendszeresen el kell távolítania az ideiglenes buildelési összetevőket a fájlrendszerből. A hálózatelkülönítés csak a buildügynök kimenő forgalmának engedélyezésével érhető el, mivel az Azure DevOpsszal való 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 ismeret alapján, és a támadások elkerülése érdekében a lehető legnagyobb mértékben csökkentse a biztonsági rések kitettségét. Alapos eljárással áttekintheti a biztonsági rések kódját . Használjon biztonsági csoportokat erre a célra, és implementáljon egy jóváhagyási folyamatot, amely üzleti indokokon alapul.
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 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 rendelkeznie kell ezeknek az összetevőknek a leltárával. Tárolja a buildkörnyezeten kívül. Rendszeresen ellenőrizze, hogy a jegyzék egyezik-e a buildelési folyamat adataival. Ezzel biztosíthatja, hogy a hátsó ajtókat vagy más kártevőket tartalmazó új összetevők ne legyenek váratlanul hozzáadva.
Lekérheti a folyamat tevékenységeit megbízható forrásokból, például az Azure Marketplace-ről. Futtassa a folyamat szállítója által írt feladatokat. A GitHub-feladatokat vagy a GitHub Actionst javasoljuk. Ha GitHub-munkafolyamatokat használ, válassza a Microsoft által készített feladatokat. 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éréssel rendelkeznek 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. A folyamatba beépített titkos kulcstárak használata. Ne feledje, hogy bizonyos helyzetekben elkerülheti a titkos kódok használatát. Ismerje meg a számítási feladatok identitásainak használatát (a folyamathitelesítéshez) és a felügyelt identitásokat (a szolgáltatásközi hitelesítéshez).
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örnyezetben alkalmazott szigorú biztonsági vezérlőkkel. Ne csatlakozzon éles adatbázishoz nem éles alkalmazásból, és ne csatlakoztassa a nem éles összetevőket az éles hálózatokhoz.
Használja a felhasználók egy részhalmazának funkcióinak fokozatos kitettségét a kiválasztott feltételek alapján. Ha problémák merülnek fel, a hatás minimálisra csökken ezekre a felhasználókra. Ez a megközelítés egy gyakori kockázatcsökkentési stratégia, mivel csökkenti a felületi területeket. Ahogy a funkció kiforrott, és nagyobb a megbízhatósága a biztonsági garanciákban, fokozatosan kiadhatja azt a felhasználók szélesebb körének.
Az éles fázis az utolsó felelős lehetőséget nyújt a biztonsági rések megoldására. Jegyezze fel az éles környezetben megjelent aranylemezképet.
Tartsa meg az összes üzembe helyezett eszköz és azok verzióinak katalógusát. Ez az információ hasznos az incidensek osztályozása, a problémák enyhítése és a rendszer működő állapotba való visszavétele során. A verziószámozott eszközök összehasonlíthatók a közzétett közös biztonsági résekkel és kitettségekkel (CVE) kapcsolatos közleményekkel is. Ezeket az összehasonlításokat automatizálással végezheti el.
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.
A kiadás általában több jóváhagyási kapuhoz van társítva. Érdemes lehet vészhelyzeti folyamatot létrehozni 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 rendszeres üzembe helyezé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ényelemmel szemben. 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, gondosan gondolja át, hogy mely automatizált teszteket lehet megkerülni. É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.
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ő fázisokban tárgyalt fogalmak erre a fázisra vonatkoznak, mivel a követelmények idővel változnak.
Javítások kezelése. 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, visszajelzések, tanulságok és a folyamatosan változó fenyegetések figyelembevételével.
Elavult vagy már nem használt ö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 tapasztal az éles környezetben, azonnal integrálnia kell őket a folyamatba, hogy ne ismétlődjenek.
Folyamatosan fejlesztheti biztonságos kódolási eljárásait, hogy lépést tartson a veszélyforrások helyzetével.
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 Defender for DevOps és a SAST-eszközök a GitHub Advanced Security vagy az Azure DevOps részeként érhetők el. Ezek az eszközök segíthetnek a szervezet biztonsági pontszámának nyomon követésében.
Kövesse az alábbi erőforrásokban leírt Azure-biztonsági javaslatokat:
Biztonságos alkalmazások fejlesztése az Azure szolgáltatásban
Ajánlott fejlesztési eljárások biztonságossá tételéhez az Azure-ban
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 erőforrások segíthetnek az értékelésben:
- Mend Bolt
- npm-audit
- OWASP Dependency-Check
- GitHub Dependabot
- Microsoft Security DevOps Azure DevOps-bővítmény
- Az OWASP biztonságos kódolási eljárásai
- OWASP Top 10
- A biztonságot támogató felhőtervezési minták
- Biztonságos alkalmazások tervezése az Azure-ban
- Biztonságos alkalmazások üzembe helyezése az Azure-ban
- Biztonságos alkalmazások fejlesztése az Azure szolgáltatásban
- Microsoft Security Development Lifecycle
- Szegmentálási stratégia kialakítására vonatkozó javaslatok
- Javaslatok az erőforrások megerősítéséhez
- Javaslatok az alkalmazás titkos kulcsainak kezelésére
- Biztonsági tesztelési javaslatok
- Javaslatok fenyegetéselemzéshez
- Ajánlott fejlesztési eljárások biztonságossá tételéhez az Azure-ban
- Oktatás: Megtudhatja, hogyan támogatja a Microsoft a biztonságos szoftverfejlesztést egy kiberbiztonsági megoldás részeként
- Platform használata szolgáltatásként (PaaS)
Tekintse meg a javaslatok teljes készletét.