Karanténminta

A harmadik féltől származó szoftverösszetevőket csak akkor használja fel az ellátási láncban, ha az ellenőrzött és biztonságosként megjelölt, jól meghatározott folyamatok alapján. Ez a minta a fejlesztési folyamat operatív oldalkocsija. A minta felhasználója ezt a folyamatot arra hívja meg, hogy ellenőrizze és tiltsa le az olyan szoftverek használatát, amelyek biztonsági réseket okozhatnak.

Kontextus és probléma

A felhőmegoldások gyakran külső forrásból beszerzett szoftverekre támaszkodnak. A nyílt forráskódú bináris fájlok, a nyilvános tárolórendszerképek és a szállítói operációs rendszer lemezképei néhány példát mutatnak az ilyen típusú összetevőkre. Minden ilyen külső összetevőt nem megbízhatóként kell kezelni.

Egy tipikus munkafolyamatban a rendszer lekéri az összetevőt a megoldás hatókörén kívüli tárolóból, majd integrálódik az üzembe helyezési folyamatba. Ebben a megközelítésben van néhány lehetséges probléma. Előfordulhat, hogy a forrás nem megbízható, az összetevő biztonsági réseket tartalmaz, vagy más módon nem alkalmas a fejlesztői környezet számára.

Ha ezeket a problémákat nem kezelik, a megoldás adatintegritási és bizalmassági garanciái sérülhetnek, vagy instabilitást okozhatnak más összetevőkkel való összeegyeztethetetlenség miatt.

Ezen biztonsági problémák némelyike elkerülhető, ha ellenőrzéseket ad hozzá az egyes összetevőkhöz.

Megoldás

Rendelkezik egy olyan eljárással, amely ellenőrzi a szoftvert a biztonság szempontjából, mielőtt bevezeti azt a számítási feladatba. A folyamat során minden összetevő alapos működési szigoron megy keresztül, amely bizonyos feltételek mellett ellenőrzi azt. Csak azután, hogy az összetevő megfelel ezeknek a feltételeknek, a folyamat megbízhatóként jelöli meg.

A quarantining folyamata egy biztonsági intézkedés, amely ellenőrzőpontok sorozatából áll, amelyeket az összetevők felhasználása előtt alkalmaznak. Ezek a biztonsági ellenőrzőpontok biztosítják, hogy egy összetevő áttérjen egy nem megbízható állapotról egy megbízható állapotra.

Fontos megjegyezni, hogy a karanténfolyamat nem változtatja meg az összetevő összetételét. A folyamat független a szoftverfejlesztési ciklustól, és szükség esetén a fogyasztók is meghívják. Az összetevő felhasználójaként tiltsa le az összetevők használatát, amíg át nem léptek a karanténon.

Íme egy tipikus karantén-munkafolyamat:

1. A fogyasztó jelzi a szándékát, megadja az összetevő bemeneti forrását, és letiltja annak használatát.

2. A karanténfolyamat ellenőrzi a kérés eredetét, és lekéri az összetevőket a megadott tárolóból.

3. A karantén részeként egyéni ellenőrzési folyamat történik, amely magában foglalja a bemeneti korlátozások ellenőrzését, valamint az attribútumok, a forrás és a típus meghatározott szabványok szerinti ellenőrzését.

   Ezen biztonsági ellenőrzések némelyike lehet sebezhetőség-vizsgálat, kártevőészlelés stb. az egyes elküldött összetevők esetében.

   A tényleges ellenőrzések az összetevő típusától függenek. Az operációsrendszer-rendszerképek kiértékelése eltér például a NuGet-csomagok kiértékelésétől.

4. Ha az ellenőrzési folyamat sikeres, az összetevő egy biztonságos tárolóban lesz közzétéve egyértelmű széljegyzetekkel. Ellenkező esetben nem érhető el a fogyasztó számára.

   A közzétételi folyamat tartalmazhat egy összegző jelentést, amely az ellenőrzés igazolását és az egyes ellenőrzések kritikusságát mutatja. Adja meg a jelentés lejáratát, amely után a jelentésnek érvénytelennek kell lennie, és az összetevő nem biztonságosnak minősül.

5. A folyamat a karantén végét jelzi, ha egy eseményt egy jelentéssel kísért állapotinformációval jelez.

   Az információk alapján a felhasználók dönthetnek úgy, hogy a megbízható összetevőt használják. Ezek a műveletek nem tartoznak a Karantén minta hatókörébe.

Problémák és megfontolandó szempontok

• Külső összetevőket használó csapatként győződjön meg arról, hogy megbízható forrásból származik. A választásnak a külső gyártóktól beszerzett összetevők szervezet által jóváhagyott szabványaihoz kell igazodnia. A szállítóknak meg kell felelniük a számítási feladat (és a szervezet) biztonsági követelményeinek. Győződjön meg például arról, hogy a szállító felelős közzétételi terve megfelel a szervezet biztonsági követelményeinek.

• Szegmentálás létrehozása olyan erőforrások között, amelyek megbízható és nem megbízható összetevőket tárolnak. Identitás- és hálózati vezérlőkkel korlátozhatja az engedélyezett felhasználók hozzáférését.

• Megbízható módon invokálódhat a karanténfolyamat. Győződjön meg arról, hogy az összetevőt csak véletlenül használják fel, amíg meg nem jelölik megbízhatóként. A jelzést automatizálni kell. Például a felelős felek értesítésével kapcsolatos feladatok, amikor egy összetevőt betöltenek a fejlesztői környezetbe, módosításokat véglegesítenek egy GitHub-adattárban, hozzáadnak egy lemezképet egy privát beállításjegyzékhez stb.

• A karanténminta implementálásának alternatívája az, ha kiszervezi azt. Vannak karanténkezelő szakemberek, akik üzleti modellként a nyilvános eszközök érvényesítésére specializálódtak. Értékelje a minta megvalósításának pénzügyi és működési költségeit, és ne a felelősség kiszervezését. Ha a biztonsági követelmények nagyobb ellenőrzést igényelnek, javasoljuk a saját folyamat implementálását.

• Automatizálja az összetevő betöltési folyamatát és az összetevő közzétételének folyamatát is. Mivel az érvényesítési tevékenységek időigényesek lehetnek, az automatizálási folyamatnak mindaddig folytatnia kell, amíg az összes tevékenység be nem fejeződik.

• A minta első lehetőség pillanatnyi ellenőrzésként szolgál. A karantén sikeres átadása nem biztosítja, hogy az összetevő határozatlan ideig megbízható maradjon. Az összetevőnek továbbra is folyamatos vizsgálaton, folyamat-ellenőrzésen és egyéb rutin biztonsági ellenőrzéseken kell átesnie, amelyek utolsó lehetőségként szolgálnak a kiadás előmozdítása előtt.

• A mintát egy szervezet központi csapatai vagy egy egyéni számítási feladatokat végző csapat implementálhatja. Ha a karanténfolyamatnak számos példánya vagy változata létezik, ezeket a műveleteket a szervezetnek szabványosítottnak és központosítottnak kell lennie. Ebben az esetben a számítási feladatok csapatai megosztják a folyamatot, és kihasználják a folyamatkezelés kiszervezésének előnyeit.

Mikor érdemes ezt a mintát használni?

Használja ezt a mintát, ha:

• A számítási feladat integrál egy, a számítási feladatokkal kapcsolatos csapat hatókörén kívül kifejlesztett összetevőt. Néhány általános példa:

  • Open Container Initiative (OCI) összetevő nyilvános adatbázisokból, például DockerHubból, GitHub Container Registryből, Microsoft Container Registryből

  • Nyilvános forrásokból származó szoftvertár vagy -csomag, például a NuGet-katalógus, a Python-csomagindex, az Apache Maven-adattár

  • Külső IaC-csomag, például Terraform-modulok, Community Chef-szakácskönyvek, Azure Verified Modules

  • Szállító által megadott operációsrendszer-rendszerkép

• A számítási feladatokért felelős csapat úgy véli, hogy az összetevő olyan kockázat, amelyet érdemes enyhíteni. A csapat tisztában van a sérült összetevők integrálásának negatív következményeivel és a karantén értékével a megbízható környezet biztosításában.

• A csapat világosan és közösen ismeri azokat az érvényesítési szabályokat, amelyeket egy összetevőtípusra alkalmazni kell. Konszenzus nélkül előfordulhat, hogy a minta nem lesz hatékony.

  Ha például az operációsrendszer-rendszerképek karanténba helyezésekor különböző ellenőrzési ellenőrzéseket alkalmaznak, az operációsrendszer-rendszerképek általános ellenőrzési folyamata inkonzisztenssé válik.

Nem érdemes ezt a mintát használni, ha:

• A szoftverösszetevőt a számítási feladatokért felelős csapat vagy egy megbízható partnercsapat hozza létre.

• Az összetevő ellenőrzésének elmaradása kevésbé költséges, mint a karanténfolyamat létrehozásának és fenntartásának költsége.

Számítási feladatok tervezése

Az építészeknek és a számítási feladatokért felelős csapatnak értékelnie kell, hogyan használható a karanténminta a számítási feladat DevSecOps-eljárásainak részeként. Az alapelveket az Azure Well-Architected Framework pillérei ismertetik.

Mint minden tervezési döntésnél, fontolja meg az ezzel a mintával bevezethető többi pillér céljaival szembeni kompromisszumokat.

Példa

Ez a példa egy olyan forgatókönyvre alkalmazza a megoldási munkafolyamatot , amelyben a számítási feladatok csapata integrálni szeretné az OCI-összetevőket a nyilvános regisztrációs adatbázisokból egy Azure Container Registry-példányba (ACR), amely a számítási feladatért felelős csapat tulajdonában van. A csapat ezt a példányt megbízható összetevő-tárolóként kezeli.

A számítási feladatok környezete az Azure Policy for Kubernetes használatával kényszeríti ki a szabályozást. Csak a megbízható beállításjegyzék-példányból korlátozza a tároló lekérését. Emellett az Azure Monitor-riasztások úgy vannak beállítva, hogy észleljék a beállításjegyzékbe váratlan forrásokból származó importálásokat.

1. A számítási feladatokkal foglalkozó csapat külső rendszerképre vonatkozó kérést az Azure Web Appsben üzemeltetett egyéni alkalmazáson keresztül küld. Az alkalmazás csak a jogosult felhasználóktól gyűjti a szükséges információkat.

   Biztonsági ellenőrzőpont: A rendszer ellenőrzi a kérelmező identitását, a céltároló beállításjegyzékét és a kért rendszerképforrást.

2. A kérés az Azure Cosmos DB-ben van tárolva.

   Biztonsági ellenőrzőpont: A rendszer az adatbázisban megőrzi az auditnaplót, amely nyomon követi a kép lefutását és érvényesítését. Ez a nyomvonal az előzményjelentéshez is használható.

3. A kérést egy munkafolyamat-vezénylő kezeli, amely egy tartós Azure-függvény. A vezénylő pontgyűjtő megközelítést használ az összes ellenőrzés futtatásához.

   Biztonsági ellenőrzőpont: A vezénylő olyan felügyelt identitással rendelkezik, amely elegendő hozzáféréssel rendelkezik az érvényesítési feladatok elvégzéséhez.

4. A vezénylő kérést intéz a rendszerkép importálására a nem megbízható tárolóként számon tartott karanténba helyezett Azure Container Registrybe (ACR).

5. A karanténregisztrációs adatbázis importálási folyamata lekéri a rendszerképet a nem megbízható külső adattárból. Ha az importálás sikeres, a karanténregisztrációs adatbázis helyi másolatot készít a rendszerképről az ellenőrzések végrehajtásához.

   Biztonsági ellenőrzőpont: A karanténregisztrációs beállításjegyzék védelmet nyújt az ellenőrzési folyamat során történő illetéktelen beavatkozás és a számítási feladatok felhasználása ellen.

6. A vezénylő az összes érvényesítési feladatot a kép helyi másolatán futtatja. A feladatok közé tartoznak az ellenőrzések, például a gyakori biztonsági rések és kitettségek (CVE) észlelése, az anyagjegyzék (SBOM) kiértékelése, a kártevők észlelése, a képaláírás és más műveletek.

   A vezénylő határozza meg az ellenőrzések típusát, a végrehajtás sorrendjét és a végrehajtás időpontját. Ebben a példában az Azure Container Instance-t használja feladatfuttatóként, az eredmények pedig a Cosmos DB auditadatbázisában találhatók. Minden tevékenység jelentős időt vehet igénybe.

   Biztonsági ellenőrzőpont: Ez a lépés az összes érvényesítési ellenőrzést végrehajtó karanténfolyamat lényege. Az ellenőrzések típusa lehet egyéni, nyílt forráskódú vagy szállító által vásárolt megoldás.

7. A vezénylő dönt. Ha a rendszerkép megfelel az összes ellenőrzésnek, az esemény megjelenik a naplózási adatbázisban, a rendszer leküldi a rendszerképet a megbízható beállításjegyzékbe, a helyi példány pedig törlődik a karanténregisztrációs adatbázisból. Ellenkező esetben a rendszer törli a rendszerképet a karanténregisztrációs adatbázisból, hogy megakadályozza annak véletlen használatát.

   Biztonsági ellenőrzőpont: A vezénylő fenntartja a szegmentációt a megbízható és a nem megbízható erőforráshelyek között.

   Feljegyzés

   Ahelyett, hogy a vezénylő meghozta a döntést, a számítási feladatért felelős csapat vállalhatja ezt a felelősséget. Ebben az esetben a vezénylő egy API-n keresztül teszi közzé az érvényesítési eredményeket, és a rendszerképet egy ideig a karanténregisztrációs adatbázisban tárolja.

   A számítási feladatokért felelős csapat az eredmények áttekintése után hozza meg a döntést. Ha az eredmények megfelelnek a kockázattűrésüknek, lekéri a rendszerképet a karantén-adattárból a tárolópéldányba. Ez a lekéréses modell gyakorlatiasabb, ha ezt a mintát több számítási feladatcsoport támogatására használják, különböző biztonsági kockázattűrésekkel.

Az összes tárolóregisztrációs adatbázist a Microsoft Defender for Containers tartalmazza, amely folyamatosan vizsgálja az újonnan talált problémákat. Ezek a problémák a Microsoft Defender biztonságirés-kezelés jelennek meg.

Következő lépések

A minta megvalósításakor az alábbi útmutatás lehet releváns:

• Javaslatok a fejlesztési életciklus biztonságossá tételéhez útmutatást nyújt a megbízható kódegységek használatával kapcsolatban a fejlesztési életciklus minden szakaszában.

• Ajánlott eljárások a biztonságos szoftverellátási lánchoz , különösen akkor, ha NuGet-függőségek vannak az alkalmazásban.

• Az Azure Artifacts dokumentációja az Azure Artifacts szoftvercsomagjainak kezelésével kapcsolatos információtár.