DevSecOps az Azure Kubernetes Service-ben (AKS)

Azure Boards

Azure DevOps

Azure Monitor

Azure Pipelines

Azure Policy

A DevSecOps, más néven a Secure DevOps a DevOps gyakorlatára épül, a hagyományos DevOps-életciklus különböző szakaszaiban a biztonság beépítésével. A DevOps-eljárásokban a biztonság kiépítésének néhány előnye:

Alkalmazások és rendszerek biztonságosabbá tétele a biztonsági fenyegetések láthatóságának biztosításával és a biztonsági rések üzembe helyezett környezetek elérésének megakadályozásával
A biztonsági tudatosság növelése a fejlesztési és üzemeltetési csapatokkal
Automatizált biztonsági folyamatok beépítése a szoftverfejlesztési életciklusba
A megoldás költségeinek csökkentése a fejlesztési és tervezési fázisok korai szakaszában jelentkező biztonsági problémák megkeresésével

Ha a DevSecOpsot az Azure Kubernetes Service(AKS) szolgáltatásra alkalmazza a rendszer, a különböző szervezeti szerepköröknek különböző szempontokat kell figyelembe venniük a biztonság implementálásához. Ilyen szervezeti szerepkörök például a következők:

Az AKS-en futó biztonságos alkalmazásokat fejlesztő fejlesztők
A felhőmérnökök biztonságos AKS-infrastruktúrát építenek
Különböző üzemeltetési csapatok, amelyek szabályozhatják a fürtöket vagy figyelhetik a biztonsági problémákat

Ez a cikk különböző DevOps-életciklus-szakaszokra bontható, a biztonsági vezérlők és a biztonsági ajánlott eljárások beágyazására vonatkozó szempontok és javaslatok figyelembe vételével. Ez az útmutató olyan gyakori folyamatokat és eszközöket tartalmaz, amelyek beépíthetők a folyamatos integrációs és folyamatos kézbesítési (CI/CD) folyamatokba, és könnyen használható beépített eszközöket választanak, ahol elérhetőek.

A cikk előfeltételeként javasoljuk, hogy tekintse át az alkalmazások AKS-en való buildeléséhez és üzembe helyezéséhez a DevOps és a GitOps használatával.

Folyamat

Töltse le az architektúra Visio-fájlját.

Feljegyzés

Bár ez a cikk az AKS-re és a GitHubra hivatkozik, ezek a javaslatok minden tárolóvezénylésre vagy CI/CD-platformra vonatkoznak. Bár a megvalósítás részletei eltérőek lehetnek, az egyes szakaszokban említett fogalmak és eljárások többsége továbbra is releváns és alkalmazható.

A Microsoft Entra ID a GitHub identitásszolgáltatójaként van konfigurálva. Konfigurálja a többtényezős hitelesítést (MFA) a további hitelesítési biztonság érdekében.
A fejlesztők a Visual Studio Code-ot vagy a Visual Studio-t olyan biztonsági bővítményekkel használják, amelyek lehetővé teszik a kód proaktív elemzését a biztonsági rések érdekében.
A fejlesztők alkalmazáskódot véglegesítenek egy vállalati tulajdonban lévő és szabályozott GitHub Enterprise-adattárban.
A GitHub Enterprise integrálja az automatikus biztonsági és függőségvizsgálatot a GitHub Advanced Securityen keresztül.
A lekéréses kérelmek folyamatos integrációs (CI) buildeket és automatizált tesztelést váltanak ki a GitHub Actions használatával.
A Ci buildelési munkafolyamata a GitHub Actionsen keresztül létrehoz egy Docker-tárolórendszerképet, amelyet az Azure Container Registry tárol.
A GitHub Actions folyamatos kézbesítési (CD) munkafolyamatának részeként manuális jóváhagyásokat vezethet be az üzembe helyezésekhez bizonyos környezetekhez, például az éles környezetekhez.
A GitHub Actions engedélyezi a CD-t az AKS-be. A GitHub Advanced Security használatával titkos kulcsokat, hitelesítő adatokat és egyéb bizalmas információkat észlelhet az alkalmazás forrás- és konfigurációs fájljaiban.
A Microsoft Defender az Azure Container Registry, az AKS-fürt és az Azure Key Vault biztonsági réseinek vizsgálatára szolgál.
1. A Microsoft Defender for Containers a Tárolóregisztrációs adatbázisba való feltöltéskor megvizsgálja a tárolórendszerkép ismert biztonsági réseit.
2. A Defender for Containers használatával is elvégezheti az AKS-környezet vizsgálatát, és futásidejű fenyegetésvédelmet biztosít az AKS-fürtök számára.
3. A Key Vaulthoz készült Microsoft Defender észleli a Key Vault-fiókok elérésére tett káros és szokatlan gyanús kísérleteket.
Az Azure Policy alkalmazható a Container Registryre és az Azure Kubernetes Service-re (AKS) a szabályzatok megfelelősége és érvényesítése érdekében. A Tárolóregisztrációs adatbázis és az AKS általános biztonsági szabályzatai a gyors engedélyezéshez vannak beépítve.
Az Azure Key Vault segítségével biztonságosan injektálhat titkos kulcsokat és hitelesítő adatokat egy alkalmazásba futtatókörnyezetben, elkülönítve a fejlesztőktől a bizalmas információkat.
Az AKS hálózati házirendmotor úgy van konfigurálva, hogy a Kubernetes hálózati házirendek használatával biztosítsa az alkalmazás podok közötti forgalmat.
Az AKS-fürt folyamatos monitorozása az Azure Monitor és a Container Insights használatával állítható be a teljesítménymetrikák betöltéséhez, valamint az alkalmazás- és biztonsági naplók elemzéséhez.
1. A Container Insights lekéri a teljesítménymetrikákat, valamint az alkalmazás- és fürtnaplókat.
2. A diagnosztikai és alkalmazásnaplók egy Azure Log Analytics-munkaterületre kerülnek napló lekérdezések futtatásához.
A Microsoft Sentinel, amely egy biztonsági információ- és eseménykezelési (SIEM) megoldás, használható az AKS-fürtnaplók betöltésére és további elemzésére a meghatározott minták és szabályok alapján bármilyen biztonsági fenyegetés esetén.
Az olyan nyílt forráskódú eszközök, mint a Zed Attack Proxy (ZAP) (ZAP) a webes alkalmazások és szolgáltatások behatolástesztelésére használhatók.
A Felhőhöz készült Defender-ben elérhető Defender for DevOps lehetővé teszi a biztonsági csapatok számára a DevOps biztonságát többfolyamatos környezetekben, például a GitHubon és az Azure DevOpsban.

A csapattagok áttekintése és feladatai

Fontolja meg a DevSecOps összetettségének kezelését a Kubernetes-alapú megoldástelepítéseken a problémák elkülönítéseként. Egy vállalati környezetben melyik csapatnak kell foglalkoznia az üzembe helyezés minden aspektusával? Milyen eszközöket és folyamatokat kell alkalmaznia egy csapatnak a céljaik legjobb elérése érdekében? Ebben a szakaszban a fejlesztők, az alkalmazásüzemeltetők (webhely-megbízhatósági mérnökök), a fürtüzemeltetők és a biztonsági csapatok közös szerepköreit ismertetjük.

Fejlesztők

A fejlesztők feladata az alkalmazáskód megírása. Ők is felelősek a kódjuknak a kijelölt adattárban való véglegesítéséért. A fejlesztők egyik fontos feladata az automatizált teszteléshez használt szkriptek létrehozása és futtatása is, hogy a kód a kívánt módon működjön, és zökkenőmentesen integrálható legyen az alkalmazás többi részével. Emellett definiálják és szkriptelik a tárolólemezképek készítését az automatizálási folyamat részeként.

Alkalmazásüzemeltetők (hely-megbízhatósági mérnökök)

A felhőbeli alkalmazások tárolók és Kubernetes használatával történő létrehozása leegyszerűsítheti az alkalmazások fejlesztését, üzembe helyezését és méretezhetőségét. Ezek a fejlesztési megközelítések azonban egyre elosztottabb környezeteket is létrehoznak, amelyek bonyolítják az adminisztrációt. A hely megbízhatósági mérnökei megoldásokat építenek ki a nagy szoftverrendszerek felügyeletének automatizálására. Hidat képeznek a fejlesztési és a fürtüzemeltető csapatok között, és segítenek a szolgáltatási szintű célkitűzések és hibakeretek kialakításában és monitorozásában. Ily módon segítenek az alkalmazástelepítések kezelésében, és gyakran Kubernetes-jegyzékfájlokat (YAML-fájlokat) írnak.

Fürt operátorai

A fürtinfrastruktúra konfigurálása és kezelése a fürtüzemeltetők feladata. Gyakran használják az infrastruktúrát kódként (IaC) ajánlott eljárásokként és keretrendszerekként, például a GitOpst a fürtök kiépítéséhez és karbantartásához. Különböző monitorozási eszközöket használnak, például az Azure Monitor Container Insightst és a Prometheus/Grafana-t a fürt általános állapotának monitorozásához. Ők felelősek a fürt javításáért, fürtfrissítéseiért, engedélyeiért és szerepköralapú hozzáférés-vezérléséért. A DevSecOps-csapatokban biztosítják, hogy a fürtök megfeleljenek a csapat biztonsági követelményeinek, és a biztonsági csapattal együttműködve hozzák létre ezeket a szabványokat.

Biztonsági csapat

A biztonsági csapat feladata a biztonsági szabványok kidolgozása és betartatása. Előfordulhat, hogy egyes csapatok felelősek a fürtöket tartalmazó előfizetésekben és erőforráscsoportokban kikényszerített Azure Policy létrehozásáért és kiválasztásáért. Figyelik a biztonsági problémákat, és a többi csapattal együtt gondoskodnak arról, hogy a devSecOps-folyamat minden lépésében előtérbe kerüljön a biztonság.

A DevSecOps életciklusának szakaszai

A biztonsági vezérlők a szoftverfejlesztési életciklus (SDLC) minden fázisában implementálva vannak. Ez az implementáció a DevSecOps-stratégia és a bal oldali megközelítés kulcsfontosságú eleme.

Töltse le az architektúra Visio-fájlját.

Tervezés fázisa

A tervfázis általában a legkisebb mértékű automatizálással rendelkezik, de olyan fontos biztonsági következményekkel jár, amelyek jelentősen befolyásolják a DevOps későbbi életciklus szakaszait. Ez a fázis magában foglalja a biztonsági, fejlesztési és üzemeltetési csapatok közötti együttműködést. A tervezés és tervezés ezen szakaszában a biztonsági érdekelt felek bevonása biztosítja, hogy a biztonsági követelmények és a biztonsági problémák megfelelően legyenek figyelembe véve vagy enyhítve.

Ajánlott eljárás – Biztonságosabb alkalmazásplatform tervezése

A biztonságosabb AKS által üzemeltetett platform létrehozása fontos lépés annak biztosításához, hogy a biztonság minden rétegben a rendszerbe legyen beépítve, kezdve a platformmal. A platform tartalmazhat a fürt belső összetevőit (például futtatókörnyezeti biztonsági és szabályzatügynökök), valamint az AKS-n kívüli összetevőket (például hálózati tűzfalakat és tárolóregisztrációs adatbázisokat). További információkért lásd az AKS célzónagyorsítót, amely olyan kritikus tervezési területeket tartalmaz, mint a biztonság, az identitás és a hálózati topológia.

Ajánlott eljárás – Fenyegetésmodellezés létrehozása a folyamatba

A fenyegetésmodellezés általában egy manuális tevékenység, amely biztonsági és fejlesztési csapatokat is magában foglal. A rendszer fenyegetéseinek modellezésére és keresésére szolgál, így a biztonsági rések a kód fejlesztése vagy a rendszer módosítása előtt kezelhetők. A fenyegetésmodellezés különböző időpontokban történhet, amelyeket olyan események válthatnak ki, mint a jelentős szoftverváltozás, a megoldás architektúraváltozása vagy a biztonsági incidensek.
Javasoljuk, hogy használja a STRIDE fenyegetésmodellt. Ez a módszertan egy adatfolyam-diagrammal kezdődik, és a STRIDE mnemonic (hamisítás, illetéktelen módosítás, információfelfedés, megrovás, szolgáltatásmegtagadás és jogosultságszint-emelés) fenyegetéskategóriákkal segít a csapatoknak a kockázatok azonosításában, enyhítésében és érvényesítésében. Emellett egy modellezési eszközt is tartalmaz a rendszerösszetevők, az adatfolyamok és a biztonsági határok jelölésére és megjelenítésére. A fenyegetésmodellezés SDLC-folyamatokba való beépítése új folyamatokat vezet be, és több munkát végez a frissített fenyegetésmodellek karbantartásán. Ez azonban segít biztosítani, hogy a biztonság korán elérhető legyen, ami segít csökkenteni a későbbi SDLC-szakaszokban előforduló biztonsági problémák kezelésének lehetséges költségeit.

Ajánlott eljárás – Az Azure Well Architect Framework (WAF) alkalmazása

A WAF biztonsági pillér ajánlott eljárásainak alkalmazása, amelyek útmutatást nyújtanak az identitáskezeléshez, az alkalmazásbiztonsághoz, az infrastruktúra-védelemhez, a dátumbiztonsághoz és a DevOpshoz, mivel az a natív felhőkörnyezetekre vonatkozik.
A WAF működési ajánlott eljárásainak alkalmazása a DevSecOpsra és az éles környezetek monitorozására.

Fejlesztés fázisa

A "Balra tolódás" a DevSecOps-gondolkodásmód kulcsbérlése. Ez a folyamat még a kód adattárba való véglegesítését és folyamaton keresztüli üzembe helyezését megelőzően kezdődik. A biztonságos kódolás ajánlott eljárásainak bevezetése, valamint a kódelemzéshez szükséges IDE-eszközök és beépülő modulok használata a fejlesztési fázis során segíthet a fejlesztési életciklus korábbi szakaszaiban felmerülő biztonsági problémák megoldásában, ha azok könnyebben megoldhatók.

Ajánlott eljárás – Biztonságos kódolási szabványok kikényszerítése

A bevált biztonságos kódolási ajánlott eljárások és ellenőrzőlisták használatával megvédheti a kódot az olyan gyakori biztonsági résektől, mint az injektálás és a nem biztonságos kialakítás. Az OWASP alapítvány az iparági szabványnak megfelelő biztonságos kódolási javaslatokat tesz közzé, amelyeket a kód írásakor ajánlott elfogadni. Ezek az irányelvek különösen fontosak a nyilvános elérésű webalkalmazások vagy -szolgáltatások fejlesztésekor.
Az általános biztonsági ajánlott eljárások mellett érdemes áttekinteni az adott programozási nyelvi futtatókörnyezetek , például a Java és a .NET biztonságos kódolási eljárásait is.
Naplózási szabványokat is kikényszeríthet, hogy megvédje a bizalmas információkat az alkalmazásnaplókba való kiszivárgástól. A legnépszerűbb naplózási keretrendszerek, például a log4j és a log4net, szűrőket és beépülő modulokat biztosítanak a bizalmas információk, például a fiókszámok vagy a személyes adatok maszkolásához.

Ajánlott eljárás – IDE-eszközök és beépülő modulok használata a biztonsági ellenőrzések automatizálásához

A legnépszerűbb azonosítók, például a Visual Studio, a Visual Studio Code, az IntelliJ IDEA és az Eclipse olyan bővítményeket támogatnak, amelyekkel azonnali visszajelzést kaphat, és javaslatokat kaphat az alkalmazáskód írása során esetlegesen felmerülő biztonsági problémákra.

A SonarLint egy IDE beépülő modul, amely a legnépszerűbb nyelvekhez és fejlesztői környezetekhez érhető el. A SonarLint értékes visszajelzést nyújt, és automatikusan megvizsgálja a kódot a gyakori programozási hibák és a lehetséges biztonsági problémák után.
Az egyéb ingyenes és kereskedelmi beépülő modulok a biztonsági elemekre összpontosítanak, például az OWASP 10 leggyakoribb biztonsági résére. A Synk beépülő modul például megvizsgálja az alkalmazás forrását és külső függőségeit, és riasztásokat küld, ha biztonsági rések találhatók.
A Visual Studióhoz és a Visual Studio Code-hoz készült Static Analysis Results Interchange Format (SARIF) beépülő modul segítségével könnyen áttekintheti a népszerű Statikus alkalmazásbiztonsági tesztelési (SAST) eszközök biztonsági réseit intuitív és könnyen olvasható módon, szemben a nyers JSON-kimeneti fájlok eredményeinek értelmezésével.

Ajánlott eljárás – Vezérlők létrehozása a forráskódtárakon

Hozzon létre egy elágaztatási módszertant, hogy következetesen használhassa az elágaztatást a vállalaton belül. Az olyan módszertanok, mint a Kiadási folyamat és a GitHub-folyamat , strukturált irányelvekkel rendelkeznek arról, hogyan kell az ágakat használni a csapat és a párhuzamos fejlesztés támogatásához. Ezek a módszerek segíthetnek a csapatoknak szabványok és vezérlők kialakításában a kód véglegesítéséhez és a CI/CD-munkafolyamatba való egyesítéshez.
Egyes ágak, például a főágak hosszú távú ágak, amelyek megőrzik az alkalmazás forráskódjának integritását. Ezeknek az ágaknak egyesítési szabályzatokat kell létrehozniuk a módosítások egyesítése vagy véglegesítése előtt. Néhány ajánlott eljárás:
- Megakadályozhatja, hogy más fejlesztők közvetlenül a fő ágba véglegesítsenek kódot.
- Hozzon létre egy társ-felülvizsgálati folyamatot, és a módosítások fő ágba való egyesítése előtt minimális számú jóváhagyást igényeljen. Ezeket a vezérlőket egyszerűen konfigurálhatja és kényszerítheti a GitHubon. A GitHub lehetővé teszi továbbá, hogy szükség esetén jogosult jóváhagyók csoportjait is kijelölje a kapus környezetekhez.
A véglegesítés előtti horogokkal ellenőrizze az alkalmazás forráskódjának bizalmas adatait, és megakadályozza a véglegesítést, ha biztonsági probléma merül fel.
- Használja a GitHub által biztosított, beépített elő véglegesítési horgokat, amelyek egyszerűen konfigurálhatók egy adott projekthez. Vannak például előre összeállított horgok, amelyek titkos kulcsokat, titkos kulcsokat és hitelesítő adatokat keresnek, és megakadályozzák a véglegesítést, ha a problémák bármelyike megtalálható.
Szerepköralapú hozzáférés-vezérlés létrehozása a verziókövetési rendszeren belül.
- Hozzon létre jól definiált szerepköröket a minimális jogosultságok elvének használatával. A CI/CD-folyamat az éles környezetek ellátási lánca.
- Meglévő felhasználói vagy csoportszerepköröket alkalmazhat a szervezeten belül. Az olyan szerepköröket, mint a Rendszergazda, a fejlesztő, a biztonsági rendszergazda és az operátor, létre kell hozni az egyének csoportosításához a CI-/CD-munkafolyamatokkal kapcsolatos szerepkörük és funkciójuk alapján.
Engedélyezze a munkafolyamatok naplózását , hogy átlátható és nyomon követhető legyen a konfiguráció és más változások a CI-/CD-folyamatokkal kapcsolatban.

Ajánlott eljárás – Tárolólemezképek védelme

Használjon könnyű képeket minimális operációsrendszer-lábnyommal a teljes felületi támadási terület csökkentéséhez. Fontolja meg az olyan minimális képeket, mint az Alpine vagy akár a disztribúció nélküli képek, amelyek csak az alkalmazást és a hozzá tartozó futtatókörnyezetet tartalmazzák. A Mariner, a Microsoft nyílt forráskódú Linux-disztribúciója egy egyszerűsített, edzett disztribúció, amelyet az AKS-hez terveztek tárolóalapú számítási feladatok üzemeltetésére.
Tárolók létrehozásakor csak megbízható alaprendszerképeket használjon. Ezeket az alaprendszerképeket egy privát beállításjegyzékből kell lekérni, amely gyakran ellenőrzi a biztonsági réseket.
A fejlesztői eszközökkel helyileg értékelje ki a rendszerkép biztonsági réseit.
- A Trivy egy nyílt forráskódú eszköz példája, amellyel elemezheti a tárolólemezképek biztonsági réseit.
A rendszerkép gyökérfelhasználói hozzáférésének/környezetének megakadályozása. Alapértelmezés szerint a tárolók gyökérként futnak.
- A fokozott biztonságot igénylő tárolók esetében fontolja meg egy AppArmor-profil használatát a Kubernetes-fürtön belül a futó tárolók biztonságának további érvényesítéséhez.

Buildelési fázis

A buildelési fázis során a fejlesztők a webhely megbízhatósági mérnökeivel és a biztonsági csapatokkal együttműködve integrálják az alkalmazás forrásának automatizált vizsgálatát a CI-buildelési folyamatokba. A folyamatok úgy vannak konfigurálva, hogy a CI/CD platform biztonsági eszközei és bővítményei segítségével engedélyezze az olyan biztonsági eljárásokat, mint az SAST, az SCA és a titkos kódok vizsgálata.

Ajánlott eljárás – Statikus kódelemzés (SAST) végrehajtása az alkalmazás forráskódjában található lehetséges biztonsági rések megkereséséhez

A GitHub Advanced Security vizsgálati képességeinek használata a kódolvasáshoz és a CodeQL-hez.
- A kódvizsgálat egy olyan funkció, amellyel elemezheti a kódot egy GitHub-adattárban, hogy biztonsági réseket és kódolási hibákat találjon. Az elemzés által azonosított problémák a GitHub Enterprise Cloudban jelennek meg.
- Ha a kódvizsgálat potenciális biztonsági rést vagy hibát talál a kódban, a GitHub riasztást jelenít meg az adattárban.
- A szükséges állapot-ellenőrzésekhez is konfigurálhat ágszabályokat, például úgy, hogy egy szolgáltatáság naprakész legyen az alapággal, mielőtt bármilyen új kódot egyesítenének. Ez a gyakorlat biztosítja, hogy az ág mindig a legújabb kóddal legyen tesztelve.
A Kubernetes üzembehelyezési objektumainak elemzéséhez használjon olyan eszközöket, mint a kube-score .
- A kube-score egy olyan eszköz, amely statikus kódelemzést végez a Kubernetes-objektumdefiníciókon.
- A kimenet azoknak a javaslatoknak a listája, amelyek segítségével biztonságosabbá és rugalmasabbá teheti az alkalmazást.

Ajánlott eljárás – Titkos kódok vizsgálata a véletlenül egy adattárban elkövetett titkos kódok csalárd felhasználásának megakadályozása érdekében

Ha a titkos kódok vizsgálata engedélyezve van egy adattárban, a GitHub olyan mintákat keres a kódban, amelyek megfelelnek a számos szolgáltató által használt titkos kódoknak.
A GitHub rendszeresen futtatja a meglévő tartalmak teljes Git-előzményeinek vizsgálatát az adattárakban, és riasztási értesítéseket küld.
- Az Azure DevOps esetében Felhőhöz készült Defender titkos kulcsok vizsgálatával észleli a hitelesítő adatokat, titkos kulcsokat, tanúsítványokat és más bizalmas tartalmakat a forráskódban és a build kimenetében.
- A titkos kódok vizsgálata a Microsoft Security DevOps for Azure DevOps bővítmény részeként futtatható.

Ajánlott eljárás – Szoftverösszetétel-elemzési (SCA) eszközök használata a kódbázis nyílt forráskódú összetevőinek nyomon követéséhez és a függőségek biztonsági réseinek észleléséhez

A függőségek áttekintése lehetővé teszi a nem biztonságos függőségek azonosítását, mielőtt bevezeti őket a környezetbe, és információkat nyújt a licencekről, a függőkről és a függőségek koráról. Könnyen érthető vizualizációt biztosít a függőségi változásokról egy lekéréses kérelem "Módosított fájlok" lapján.
A Dependabot vizsgálattal észleli a nem biztonságos függőségeket, és Dependabot-riasztásokat küld, amikor új tanácsadást ad hozzá a GitHub Advisory Database-hez, vagy ha egy adattár függőségi gráfja megváltozik.

Ajánlott eljárás – Az Infrastruktúra kódként (IaC) sablonok biztonsági vizsgálatának engedélyezése az éles környezeteket elérő felhőbeli helytelen konfigurációk minimalizálása érdekében

A felhőerőforrás-konfigurációk proaktív monitorozása a fejlesztési életciklus során.
A Microsoft Defender for DevOps a GitHub és az Azure DevOps-adattárakat is támogatja.

Ajánlott eljárás – A számítási feladatok lemezképeinek vizsgálata tárolóregisztrációs adatbázisokban az ismert biztonsági rések azonosításához

A Defender for Containers megvizsgálja a Tárolóregisztrációs adatbázisban és az Amazon AWS Elastic Container Registryben (ECR) található tárolókat, hogy értesítse Önt, ha ismert biztonsági rések találhatók a rendszerképekben.
Az Azure Policy lehetővé teszi, hogy biztonságirés-felmérést végezhessen a Container Registryben tárolt összes lemezképen, és részletes információkat nyújtson az egyes megállapításokról.

Ajánlott eljárás – Új képek automatikus létrehozása az alaprendszerkép-frissítéshez

Az Azure Container Registry Tasks dinamikusan felderíti az alaprendszerkép-függőségeket egy tárolórendszerkép létrehozásakor. Ennek eredményeképpen képes észlelni az alkalmazáslemezkép alaprendszerképének frissítését. Egy előre konfigurált buildelési feladattal a Container Registry-feladatok automatikusan újraépíthetik az alaprendszerképre hivatkozó összes alkalmazásrendszerképet.

Ajánlott eljárás – A Tárolóregisztrációs adatbázis, az Azure Key Vault és a jelölés használata a tárolólemezképek digitális aláírásához és az AKS-fürt konfigurálásához csak érvényesített rendszerképek engedélyezéséhez

Az Azure Key Vault egy aláíró kulcsot tárol, amelyet a Key Vault beépülő modul (azure-kv) jelölésével használhat a tárolólemezképek és egyéb összetevők aláírásához és ellenőrzéséhez. A Tárolóregisztrációs adatbázis lehetővé teszi, hogy ezeket az aláírásokat az Azure CLI-parancsok használatával csatolja.
Az aláírt tárolók lehetővé teszik, hogy a felhasználók meggyőződhessenek arról, hogy az üzemelő példányok megbízható entitásból készültek, és ellenőrzik, hogy az összetevőt nem módosították-e a létrehozása óta. Az aláírt összetevő biztosítja az integritást és a hitelességet, mielőtt a felhasználó bármilyen környezetbe lekér egy összetevőt, ami segít elkerülni a támadásokat.
- A Ratify lehetővé teszi, hogy a Kubernetes-fürtök az üzembe helyezés előtt ellenőrizzek az összetevők biztonsági metaadatait, és csak azokat ismerjék el, amelyek megfelelnek a létrehozott belépési szabályzatnak.

Üzembe helyezési fázis

Az üzembe helyezési fázis során a fejlesztők, az alkalmazásüzemeltetők és a fürtüzemeltetők csapatai közösen dolgoznak azon, hogy megfelelő biztonsági vezérlőket hozzanak létre a folyamatos üzembe helyezési (CD) folyamatokhoz a kód éles környezetben történő biztonságosabb és automatizáltabb üzembe helyezéséhez.

Ajánlott eljárás – Az üzembe helyezési folyamat hozzáférésének és munkafolyamatának szabályozása

A fontos ágakat ágvédelmi szabályok beállításával védheti meg. Ezek a szabályok határozzák meg, hogy a közreműködők törölhetik vagy kényszeríthetik-e a leküldést az ágra. Az ágba irányuló leküldésekre vonatkozó követelményeket is beállítanak, például állapotellenőrzéseket vagy lineáris véglegesítési előzményeket.
Környezetek üzembe helyezéshez való használatával védelmi szabályokkal és titkos kódokkal konfigurálhatja a környezeteket.
A Jóváhagyások és a Gates funkcióval szabályozhatja az üzembe helyezési folyamat munkafolyamatát. Szükség lehet például manuális jóváhagyásra egy biztonsági vagy üzemeltetési csapattól az éles környezetbe való üzembe helyezés előtt.

Ajánlott eljárás – Biztonságos üzembehelyezési hitelesítő adatok

Az OpenID Csatlakozás (OIDC) lehetővé teszi, hogy a GitHub Action-munkafolyamatok anélkül férhessenek hozzá az Azure-beli erőforrásokhoz, hogy hosszú élettartamú GitHub-titkos kulcsként kellene tárolniuk az Azure-hitelesítő adatokat.
Környezetek üzembe helyezéshez való használatával védelmi szabályokkal és titkos kódokkal konfigurálhatja a környezeteket.
- A CI/CD gitOps-alapú lekéréses megközelítése lehetővé teszi a biztonsági hitelesítő adatok áthelyezését a Kubernetes-fürtre, ami csökkenti a biztonsági és kockázati felületet azáltal, hogy eltávolítja a hitelesítő adatokat a külső CI-eszközben való tárolásból. Emellett csökkentheti az engedélyezett bejövő kapcsolatokat, és korlátozhatja a Kubernetes-fürtök rendszergazdai szintű hozzáférését.

Ajánlott eljárás – Dinamikus alkalmazásbiztonsági tesztek (DAST) futtatása a futó alkalmazás biztonsági réseinek megkereséséhez

A GitHub Actions használata az üzembehelyezési munkafolyamatokban dinamikus alkalmazásbiztonsági tesztek (DAST) futtatásához.
Használjon nyílt forráskódú eszközöket, például a ZAP-t a gyakori webalkalmazás-biztonsági rések behatolásteszteléséhez.

Ajánlott eljárás – Tárolólemezképek üzembe helyezése csak megbízható adatbázisokból

A Defender for Containers használatával engedélyezheti az Azure Policy bővítményt a Kuberneteshez.
Engedélyezze az Azure Policyt, hogy a tárolólemezképek csak megbízható adatbázisokból legyenek üzembe helyezve.

Üzemeltetési fázis

Ebben a fázisban a műveletfigyelési és biztonsági monitorozási feladatok a lehetséges biztonsági incidensek proaktív monitorozására, elemzésére és riasztására kerülnek. Az olyan éles megfigyelhetőségi eszközök, mint az Azure Monitor és a Microsoft Sentinel, a vállalati biztonsági szabványoknak való megfelelés monitorozására és biztosítására szolgálnak.

Ajánlott eljárás – A Microsoft Defender felhőhöz való használata az éles konfigurációk automatikus vizsgálatának és monitorozásának engedélyezéséhez

Futtasson folyamatos vizsgálatot az alkalmazás sebezhetőségi állapotának eltéréseinek észleléséhez, és implementáljon egy folyamatot a sebezhető képek javításához és cseréjéhez.
Automatizált konfigurációfigyelés implementálása operációs rendszerekhez.
- Az AKS-fürtök alapkonfigurációinak vizsgálatához használja Felhőhöz készült Microsoft Defender tárolójavaslatokat (a Számítás és alkalmazások szakaszban). Értesítést kaphat az Felhőhöz készült Microsoft Defender irányítópulton, ha konfigurációs problémák vagy biztonsági rések találhatók.
- Az AKS-fürtök által használt hálózati erőforrások biztonságossá tételéhez használja a Felhőhöz készült Microsoft Defender és kövesse a hálózatvédelmi ajánlásait.
Végezzen biztonságirés-felmérést a Container Registryben tárolt képekről.
- A Tárolóregisztrációs adatbázisban futó rendszerképek folyamatos vizsgálata a Defender for Containers engedélyezésével.

Ajánlott eljárás – Kubernetes-fürtök naprakészen tartása

A Kubernetes-kiadások gyakran kerülnek kiadásra. Fontos, hogy legyen egy életciklus-kezelési stratégia, amely biztosítja, hogy ne maradjon le és ne maradjon ki a támogatásból. Az AKS egy felügyelt ajánlat, amely eszközöket és rugalmasságot biztosít a frissítési folyamat kezeléséhez. Az AKS-platform tervezett karbantartási funkcióival jobban szabályozhatja a karbantartási időszakokat és a frissítéseket.
Az AKS feldolgozó csomópontjait gyakrabban kell frissíteni . Heti operációsrendszer- és futtatókörnyezeti frissítéseket biztosítunk, amelyek felügyelet nélküli módban vagy az Azure CLI-vel automatikusan alkalmazhatók a nagyobb vezérlési és átfogó frissítések érdekében.

Ajánlott eljárás – Az Azure Policy használata az AKS-fürtök védelméhez és szabályozásához

Az AKS-hez készült Azure Policy-bővítmény telepítése után egyéni szabályzatdefiníciókat vagy kezdeményezésnek (más néven szabályzatkészleteknek) nevezett szabályzatdefiníciókat alkalmazhat a fürtre.
Beépített Azure-szabályzatok használata gyakori forgatókönyvekhez, például a kiemelt tárolók futtatásának vagy csak az engedélyezett külső IP-címek jóváhagyásának megakadályozása. Egyéni szabályzatokat is létrehozhat adott használati esetekhez.
Alkalmazza a fürtre a szabályzatdefiníciókat, és ellenőrizze, hogy a hozzárendelések kikényszerítése folyamatban van-e.
A Gatekeeper használatával konfigurálhat egy olyan beléptető vezérlőt, amely engedélyezi vagy tagadja az üzemelő példányokat a megadott szabályok alapján. Az Azure Policy kibővíti a Gatekeepert.
A számítási feladatok podjai közötti forgalom védelme hálózati szabályzatok használatával az AKS-ben.
- Telepítse a hálózati házirendmotort, és hozzon létre Kubernetes-hálózati házirendeket a podok közötti forgalom szabályozásához az AKS-ben. A hálózati házirend linuxos vagy Windows-alapú csomópontokhoz és podokhoz használható az AKS-ben.

Ajánlott eljárás – Az Azure Monitor használata folyamatos figyeléshez és riasztáshoz

Az Azure Monitor használatával naplókat és metrikákat gyűjthet az AKS-ből. Elemzéseket kaphat az alkalmazás és az infrastruktúra rendelkezésre állásáról és teljesítményéről. Emellett hozzáférést biztosít a jelekhez a megoldás állapotának monitorozásához és a rendellenes tevékenységek korai észleléséhez.
- Az Azure Monitor folyamatos monitorozása kiterjed a folyamatokat a monitorozási adatokon alapuló kiadásra vagy visszaállításra. Az Azure Monitor biztonsági naplókat is betölt, és riasztást küld a gyanús tevékenységekről.
- Vegye fel az AKS-példányokat az Azure Monitorba, és konfigurálja a fürt diagnosztikai beállításait.
  - Tekintse meg az Azure Kubernetes Service azure-ra vonatkozó biztonsági alapkonfigurációit.

Ajánlott eljárás – A Felhőhöz készült Microsoft Defender használata aktív fenyegetésfigyeléshez

Felhőhöz készült Microsoft Defender aktív fenyegetésfigyelést biztosít az AKS-en csomópontszinten (virtuálisgép-fenyegetések) és belső rendszereken.
A Defender for DevOps-t az átfogó láthatóság érdekében kell használni, és a biztonsági és operátori csapatokat központosított irányítópulttal kell biztosítani az összes CI/CD-folyamathoz. Ez a funkció különösen akkor hasznos, ha többfolyamatos platformokat használ, például az Azure DevOpsot és a GitHubot, vagy folyamatokat futtat nyilvános felhőkben.
A Key Vaulthoz készült Defender a Key Vault-fiókokhoz való szokatlan, gyanús kísérletek észlelésére használható, és konfiguráció alapján riasztást adhat a rendszergazdáknak.
A Defender for Containers riasztást küld a Tárolóregisztrációs adatbázisban tárolt tárolólemezképeken található biztonsági résekre.

Ajánlott eljárás – Központosított naplófigyelés engedélyezése és SIEM-termékek használata valós idejű biztonsági fenyegetések monitorozásához

Csatlakozás AKS diagnosztikai naplóit a Microsoft Sentinelnek, hogy a minták és szabályok alapján központosított biztonsági monitorozást biztosítsunk. A Sentinel zökkenőmentesen teszi lehetővé ezt a hozzáférést adatösszekötők használatával.

Ajánlott eljárás – Naplózás engedélyezése az éles fürtök tevékenységeinek figyeléséhez

Tevékenységnaplók használatával figyelheti az AKS-erőforrások műveleteit az összes tevékenység és állapotuk megtekintéséhez. Határozza meg, hogy milyen műveleteket hajtottak végre az erőforrásokon és ki által.
Engedélyezze a DNS-lekérdezések naplózását , ha dokumentált konfigurációt alkalmaz a CoreDNS egyéni konfigurációtérképében.
Az inaktivált hitelesítő adatok elérésére tett kísérletek figyelése.
- Az AKS felhasználói hitelesítésének integrálása a Microsoft Entra-azonosítóval. Hozzon létre diagnosztikai Gépház a Microsoft Entra-azonosítóhoz, és küldje el a naplózási és bejelentkezési naplókat egy Azure Log Analytics-munkaterületre. Konfigurálja a kívánt riasztásokat (például amikor egy inaktivált fiók megpróbál bejelentkezni) egy Azure Log Analytics-munkaterületen.

Ajánlott eljárás – Diagnosztikának engedélyezése az Azure-erőforrásokon

Ha engedélyezi az Azure-diagnosztika használatát a számítási feladat összes erőforrásában, olyan platformnaplókhoz férhet hozzá, amelyek részletes diagnosztikai és naplózási információkat nyújtanak az Azure-erőforrásokhoz. Ezek a naplók betölthetők a Log Analyticsbe vagy egy SIEM-megoldásba, például a Microsoft Sentinelbe a biztonsági monitorozáshoz és riasztáshoz.

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerző:

Adnan Khan | Sr. Cloud Solution Architect

Egyéb közreműködők:

Ayobami Ayodeji | Programmenedzser 2
Ahmed Bham | Sr. Cloud Solution Architect
Chad Kittel | Fő szoftvermérnök
John Poole | Sr. Cloud Solution Architect
Bahram Rushenas | Sr. Solution Architect
Abed Sau | Sr. Cloud Solution Architect