DevSecOps az Azure Kubernetes Service-ben (AKS)

A DevSecOps, más néven Biztonságos DevOps a szoftverfejlesztési életciklus (SDLC) minden szakaszában integrálható a biztonság egy DevOps-munkafolyamaton belül. Az AKS-en futó DevSecOps ezt a megközelítést alkalmazza a Azure Kubernetes Service futó tárolóalapú alkalmazásokra, amelyek automatikus biztonsági vezérlőket ágyaznak be közvetlenül CI/CD-folyamatokba és fürtműveletekbe. A devOps-eljárások biztonsági fejlesztése a következőkkel:

• Biztonságosabbá teheti az alkalmazásait és rendszereit, áttekintheti a biztonsági fenyegetéseket, és megakadályozhatja, hogy a biztonsági rések elérjék az üzembe helyezett környezeteket.
• Növelje a biztonsági tudatosságot a fejlesztői és üzemeltetési csapatok körében.
• Az automatizált biztonsági folyamatokat beépítheti a szoftverfejlesztési életciklusba (SDLC).
• Csökkentse a szervizelési költségeket a fejlesztési és tervezési fázisok korai szakaszában felmerülő biztonsági problémák megkeresésével.

A legfontosabb tudnivalók

• A biztonság előtérbe helyezése a fejlesztés korai szakaszában: Integrálja a biztonsági ellenőrzéseket már a fejlesztés korai szakaszában IDE-bővítmények, pre-commit hookok és biztonságos kódolási szabványok alkalmazásával, hogy a sérülékenységeket még azelőtt fel lehessen deríteni, hogy a kód éles környezetbe kerülne.
• Automatizált vizsgálat: Használjon statikus alkalmazásbiztonsági tesztelést (SAST), szoftverösszetétel-elemzést (SCA) és titkos kulcskeresést a CI-folyamatokban a kód biztonsági réseinek, a nem biztonságos függőségeknek és a hitelesítő adatok automatikus felfedéséhez.
• Szabályzatkényszerítés: Azure Container Registry konfigurációk naplózása Azure Policy használatával. Az AKS-beléptetés kényszerítése érdekében használja az AKS Azure Policy bővítményét, amely kibővíti a Gatekeepert.
• Folyamatos monitorozás: Futtatókörnyezeti veszélyforrások elleni védelem implementálása a tárolókhoz készült Microsoft Defender, a központosított naplózás Azure Monitor és a Microsoft Sentinel SIEM-integrációjával.
• Ellátási lánc biztonsága: SBOM-ok létrehozása, tárolólemezképek aláírása és üzembe helyezése csak megbízható adatbázisokból az összetevők integritásának fenntartása érdekében.

Ha DevSecOps-t alkalmaz az Azure Kubernetes Service -ra (AKS), minden szervezeti szerepkörnek konkrét biztonsági szempontokat kell figyelembe vennie:

• A fejlesztők az AKS-en futó biztonságos alkalmazásokat építenek ki.
• A felhőmérnökök biztonságos AKS-infrastruktúrát építenek ki.
• Az operatív csapatok szabályozhatják a fürtöket, vagy figyelhetik a biztonsági problémákat.

Ez a cikk útmutatást nyújt a DevOps életciklus-szakaszához, és javaslatokat nyújt a biztonsági vezérlőkhöz és az ajánlott eljárásokhoz. Bemutatja a folyamatos integrációs és folyamatos kézbesítési (CI/CD) folyamatok gyakori folyamatait és eszközeit, a beépített eszközökre összpontosítva.

Folyamat

A folyamat egy olyan fejlesztővel kezdődik, aki csatlakozik a Microsoft Entra-azonosítóhoz, és olyan fejlesztői eszközökben dolgozik, mint a Visual Studio és a Visual Studio Code. A fejlesztő leküldi a kódot a GitHubra, amely központi forrásvezérlő rendszerként szolgál. A GitHubon a folyamat folytatódik a GitHub Actionsben, ahol az automatizált lépések futnak. Más kapcsolatok mutatják a pull kérelmeket, az üzembe helyezési jóváhagyási kapukat és a biztonsági ellenőrzéseket, amelyek ehhez a szakaszhoz kapcsolódnak. A GitHub Advanced Security és a DevOps-hoz készült Microsoft Defender csatlakozik a GitHubhoz. A folyamat ezután csatlakozik az Azure Container Registryhez, amely a buildelési folyamat és az üzembe helyezési cél között helyezkedik el. Az irányítási és biztonsági ellenőrzések, beleértve a Microsoft Defendert és az Azure Policyt, ehhez a szakaszhoz csatlakoznak felülről és oldalról. A beállításjegyzékből a folyamat az AKS-be kerül, amely a futásidejű környezetet jelképező, jobb oldalon egy külön területen jelenik meg. A Kubernetes-környezet körül több csatlakoztatott összetevő elágazik. Ezek az összetevők közé tartozik az Azure Policy és a fenti Azure Key Vault, a Log Analytics és a Microsoft Sentinel jobb oldalán, valamint az alábbi eszközök, például a hálózati szabályzat, a tárolókhoz készült Azure Monitor és a Zed Attack Proxy (ZAP).

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

Note

Ez a cikk az AKS-re és a GitHubra hivatkozik, de ezeket a javaslatokat bármilyen tárolóvezénylésre vagy CI/CD-platformra alkalmazhatja. A megvalósítás részletei eltérőek lehetnek, de az egyes fázisok legtöbb fogalma és gyakorlata továbbra is érvényes.

1. 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.

2. 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.

3. A fejlesztők alkalmazáskódot véglegesítenek egy vállalati tulajdonban lévő és szabályozott GitHub Enterprise-adattárban.

4. A GitHub Enterprise integrálja az automatikus biztonsági és függőségvizsgálatot a GitHub Advanced Securityen keresztül.

5. A lekéréses kérelmek folyamatos integrációs (CI) buildeket és automatizált tesztelést váltanak ki GitHub Actions keresztül.

6. A Ci buildelési munkafolyamata a GitHub Actions használatával létrehoz egy Docker-tárolórendszerképet, és tárolja azt az Azure Container Registryben.

7. A GitHub Actions folyamatos szállítási (CD) munkafolyamatának részeként manuális jóváhagyásokat adhat hozzá a telepítésekhez különböző környezetekhez, például az éles környezet, mint például a production.

8. A GitHub Actions engedélyezi a CD-t az AKS-be. Az 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.

9. A Microsoft Defender biztonsági réseket keres a Container Registryben, az AKS-fürtben és az Azure Key Vaultban.

   1. A Microsoft Defender for Containers megvizsgálja a tárolórendszerképet az ismert biztonsági rések után, amikor a GitHub Actions feltölti a Tárolóregisztrációs adatbázisba.

   2. A Defender for Containers az AKS-környezetet is átvizsgálhatja, és futtatókörnyezeti veszélyforrások elleni védelmet biztosíthat az AKS-fürtök számára.

   3. A Key Vaulthoz készült Microsoft Defender szokatlan és gyanús kísérleteket észlel a Key Vault-fiókok elérésére.

10. Az Azure Policyt a Container Registryre és az AKS-re is alkalmazhatja a szabályzatmegfelelés kikényszerítéséhez. Az Azure Policy beépített biztonsági szabályzatokat tartalmaz a Container Registryhez és az AKS-hez is.

11. A Key Vault biztonságosan injektálja a titkos kulcsokat és a hitelesítő adatokat egy alkalmazásba futtatókörnyezetben anélkül, hogy felfedi őket a fejlesztőknek.

12. 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. Hálózati házirendmotorként az Azure CNI Powered by Ciliumot javasoljuk. Kiterjesztett Berkeley-csomagszűrő (eBPF)-alapú kényszerítést, 7. rétegbeli szabályzatot és teljes tartománynév-szűrést (FQDN) biztosít.

13. Az AKS-fürt folyamatos figyelését az Azure Monitor használatával állíthatja be Prometheus-metrikák, tárolónaplók és Kubernetes-események gyűjtéséhez. Azure Managed Grafana-irányítópultok használata vizualizációhoz és Log Analytics lekérdezésalapú riasztásokhoz.

    1. Az Azure Monitor a Menedzselt Prometheus segítségével és a konténernapló-gyűjtés révén gyűjti a teljesítménymetrikákat, valamint az alkalmazás- és fürtnaplókat.

    2. A Log Analytics-munkaterületek a diagnosztikai és alkalmazásnaplókat napló lekérdezések futtatásához tárolják.

14. A Microsoft Sentinel központi biztonsági információ és eseménykezelés (SIEM) használatával korrelálhatja az AKS-telemetriát a Microsoft Defender for Cloud, a Microsoft Entra ID és a hálózati erőforrások jelzéseivel. A Microsoft Sentinel a teljes AKS-környezetben észlelést, vizsgálatot és automatikus választ biztosít a biztonsági incidensekre.

15. A nyílt forráskódú eszközök, például a Zed Attack Proxy (ZAP) képesek behatolástesztelésre webalkalmazások és szolgáltatások esetében.

16. A Defender for Cloudban elérhető DevOps-hoz készült Defender lehetővé teszi a biztonsági csapatok számára, hogy a DevOps biztonságát többrétegű környezetekben, például a GitHubon és az Azure DevOpsban kezeljék.

A csapattagok áttekintése és feladatai

Fontolja meg a DevSecOps összetettségének kezelését a Kubernetes-alapú megoldástelepítéseken a feladatok csapatok közötti megosztásával. Ez a szakasz a fejlesztők, az alkalmazásüzemeltetők, például a webhely-megbízhatósági mérnökök, a fürtüzemeltetők és a biztonsági csapatok szerepköreit és feladatait ismerteti.

Developers

A fejlesztők megírják az alkalmazáskódot, és véglegesítik a kijelölt adattárban. Szkripteket szerkesztenek és futtatnak az automatizált teszteléshez, hogy a kód a kívánt módon működjön, és integrálva legyen az alkalmazás többi részével. A fejlesztők az automatizálási folyamat részeként definiálják és szkriptelik a tárolólemezképek létrehozását.

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

Az 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 olyan megoldásokat építenek ki, amelyek automatizálják, hogy a csapatok hogyan felügyelik a nagy szoftverrendszereket. Hidat képeznek a fejlesztési és a fürtüzemeltető csapatok között. Segítenek a szolgáltatási szintű célkitűzések (SLO-k) és a hibakeretek kialakításában és monitorozásában. A webhely-megbízhatósági mérnökök emellett segítenek kezelni az alkalmazástelepítéseket, és Kubernetes-jegyzékfájlokat (YAML-fájlokat) írni.

Klaszter operátorok

A fürtüzemeltetők konfigurálják és kezelik a fürtinfrastruktúra használatát. Gyakran használják az infrastruktúra mint kódot (IaC) legjobb gyakorlatokat és keretrendszereket, például GitOps-t a fürtök kiépítéséhez és karbantartásához. A fürt egészségi állapotának nyomon követésére olyan monitorozási eszközöket használnak, mint az Azure Monitor által kezelt szolgáltatás Prometheushoz és az Azure Managed Grafana. Ők felelősek a fürt javításáért, a frissítésekért, az engedélyekért és a szerepkör-alapú hozzáférés-vezérlésért (RBAC) a fürtön belül. A DevSecOps-csapatokban a fürtüzemeltetők a biztonsági csapatokkal együttműködve biztonsági szabványokat hoznak létre, és biztosítják, hogy a fürtök megfeleljenek ezeknek a követelményeknek.

Biztonsági csapat

A biztonsági csapat fejleszti és érvényesíti a biztonsági szabványokat. Egyes csapatok olyan Azure Policy-definíciókat hozhatnak létre és választhatnak ki, amelyeket érvényesítenek a fürtöket tartalmazó előfizetésekben és erőforráscsoportokban. A biztonsági csapatok figyelik a biztonsági problémákat, és más csapatokkal együttműködve rangsorolják a biztonságot a DevSecOps-folyamat során.

A DevSecOps életciklusának szakaszai

Az SDLC minden fázisa biztonsági vezérlőket implementál. Ezek a biztonsági vezérlők központi szerepet jelentenek a DevSecOpsban és a shift-left eljárásokban.

A középen egy biztonsági központ látható, amely a ciklus minden fázisához csatlakozik. Öt fázis veszi körül ezt a központi pontot egy hurokba rendezve: tervezés, fejlesztés, buildelés, kiadás és üzemeltetés. Minden szakasz példákat tartalmaz az adott fázisra vonatkozó biztonsági eljárásokra. A fenyegetésmodellezés, a biztonsági szabályzatok és az Azure Well-Architected-keretrendszer gyakorlata a tervezés során történik. A biztonságos kódolási szabványok és az integrált fejlesztési környezet (IDE) biztonsági beépülő moduljai a fejlesztés során fordulnak elő. A statikus alkalmazásbiztonsági tesztelés (SAST), a szoftverösszetétel-elemzés (SCA) és a titkos kódok vizsgálata a buildelés, a dinamikus alkalmazásbiztonsági tesztelés (DAST), a behatolástesztelés és a munkafolyamat-jóváhagyások során történik a kiadás során, és a naplózás, a riasztás, a SIEM és a hálózatfigyelés a működés során történik. A nyilak egymás után kötik össze a fázisokat a folyamatos folyamat megjelenítéséhez, és a kapcsolatok az egyes fázisokat visszakapcsolják a központi biztonsági függvényhez.

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 fontos biztonsági következményekkel jár, amelyek hatással vannak a DevOps későbbi életciklus-szakaszaira. 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 biztonsági követelmények és biztonsági problémák figyelembe vétele vagy enyhítése érdekében vegye fel a biztonsági érdekelt feleket ebbe a fázisba.

Ajánlott eljárás: Biztonságos alkalmazásplatform tervezése

A biztonságos AKS által üzemeltetett számítási feladatok létrehozásához minden rétegben be kell építenie a biztonságot a rendszerbe, kezdve magával a platformmal. A platform tartalmazhat a fürt belső összetevőit, például a futtatókörnyezet biztonsági és szabályzatügynökeit, valamint az AKS-hez külső összetevőket, például a hálózati tűzfalakat és a tárolóregisztrációs adatbázisokat.

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. Kód fejlesztése vagy módosítása előtt modellezheti és megkeresheti a rendszer biztonsági réseit elhárító fenyegetéseket. A Teams fenyegetésmodellezést végez a jelentős szoftverváltozásokra, a megoldás architekturális változásaira vagy a biztonsági incidensekre válaszul.

A STRIDE fenyegetésmodellt javasoljuk. Ez a módszertan egy adatfolyam-diagrammal kezdődik, és kategorizálja a fenyegetéseket a STRIDE mnemonic használatával: hamisítás, illetéktelen beavatkozás, megtagadás, információfelfedezés, szolgáltatásmegtagadás és jogosultságszint-emelés. A csapatok ezeket a kategóriákat használják a kockázatok azonosítására, enyhítésére és érvényesítésére. A modellezési eszköz segít a rendszerösszetevők, adatfolyamok és biztonsági határok jelölésében és megjelenítésében.

Ha fenyegetésmodellezést készít az SDLC-ben, a folyamat többletterhelést jelent, és a frissített fenyegetésmodellek karbantartását igényli. Azonban a fejlesztés korai szakaszában foglalkozik a biztonsággal, ami csökkenti a később felfedezett problémák kijavításának költségeit.

Ajánlott eljárás: Az Azure Well-Architected-keretrendszer alkalmazása

• Alkalmazza a biztonsági ajánlott eljárásokat, amelyek útmutatást nyújtanak az identitáskezeléshez, az alkalmazásbiztonsághoz, az infrastruktúra-védelemhez, az adatbiztonsághoz és a DevOpshoz, mivel az a natív felhőbeli környezetekre vonatkozik.

• Alkalmazza az Operational Excellence ajánlott eljárásait a DevSecOpsra és a gyártási környezetek monitorozására.

Fejlesztés fázisa

A balra tolódás a DevSecOps-gondolkodásmód kulcsfontosságú eleme. Ez a folyamat azelőtt kezdődik, hogy kódot commitálna egy adattárba, és egy pipeline-on keresztül üzembe helyezné azt. A fejlesztési életciklus korábbi szakaszában felmerülő biztonsági problémák megoldásához alkalmazzon biztonságos kódolási ajánlott eljárásokat, és használjon integrált fejlesztési környezet (IDE) eszközöket és beépülő modulokat a kódelemzéshez a fejlesztési fázisban.

Ajánlott eljárás: Biztonságos kódolási szabványok érvényesítése

• A bevált biztonságos kódolási ajánlott eljárásokkal és ellenőrzőlistákkal megvédheti a kódot az olyan gyakori biztonsági résekkel szemben, mint az injektálás és a nem biztonságos kialakítás. Az Open Worldwide Application Security Project (OWASP) alapítvány az iparági szabványnak megfelelő biztonságos kódolási javaslatokat tesz közzé, amelyeket 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.

• Tekintse át az adott programozási nyelvi futtatókörnyezetek , például a Java és a .NET biztonságos kódolási eljárásait.

• Naplózási szabványok kényszerítése a bizalmas adatok alkalmazásnaplókba való kiszivárgásának védelméhez. A legnépszerűbb naplózási keretrendszerek, például az Apache Log4j és az Apache 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 VS Code, az IntelliJ IDEA és az Eclipse olyan bővítményeket támogatnak, amelyekkel azonnali visszajelzéseket és javaslatokat kaphat az alkalmazáskód írása során felmerülő esetleges biztonsági problémákra.

• A SonarQube for IDE egy IDE beépülő modul a legnépszerűbb nyelvekhez és fejlesztői környezetekhez. Az IDE-hez készült SonarQube visszajelzést ad, és automatikusan megvizsgálja a kódot a gyakori programozási hibák és a lehetséges biztonsági problémák eseté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. Az Snyk beépülő modul emellett megvizsgálja az alkalmazás forrását és külső függőségeit, és riasztásokat küld, ha biztonsági réseket talál.

• A Visual Studióhoz és a VS Code-hoz készült Static Analysis Results Interchange Format (SARIF) beépülő modullal egyszerűen megtekintheti a népszerű Statikus alkalmazásbiztonsági tesztelési (SAST) eszközök biztonsági réseit, és értelmezheti a nyers JSON-kimeneti fájlok eredményeit.

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 a vállalat konzisztenciájához. Az olyan módszertanok, mint a Kiadási folyamat és a GitHub-folyamat, strukturált irányelvekkel rendelkeznek arról, hogyan használhatók ágak a csapat és a párhuzamos fejlesztés támogatására. 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. A módosítások véglegesítése vagy egyesítése előtt hozzon létre egyesítési szabályzatokat ezekhez az ágakhoz. Például megteheted a következőket:

  • Megakadályozhatja, hogy más fejlesztők közvetlenül kódot töltsenek fel a fő branchbe.

  • Hozzon létre egy társ-felülvizsgálati folyamatot, és igényeljen minimális számú jóváhagyást a főág módosításainak egyesítése előtt. Konfigurálja és kényszerítse ki ezeket a vezérlőket a GitHub használatával. A GitHub használatával kijelölhet engedélyezett jóváhagyók csoportjait, ha szükséges a kapus környezetekhez.

• Az előre kiírási horgokkal bizalmas információkat kereshet az alkalmazás forráskódjában, és letilthatja a véglegesítéseket, amikor biztonsági problémákat észlelnek.

  • Használja a GitHub által nyújtott, beépített előkötelezési horgokat. Egyszerűen konfigurálhatja őket adott projektekhez. Egyes előre összeállított horgok például titkokat, privát kulcsokat és hitelesítő adatokat keresnek, és blokkolják az elkötelezést, ha ilyen problémákat találnak.

• Hozza létre az RBAC-t a verziókövetési rendszeren belül.

  • Hozzon létre jól definiált szerepköröket a minimális jogosultság elvének használatával. A CI/CD-csővezeték az éles környezetek ellátási láncaként szolgál a telepítésekhez.

  • Meglévő felhasználói vagy csoportszerepköröket alkalmazhat a szervezeten belül. Ha a CI/CD-munkafolyamatokban az adott szerepkörük és funkciójuk alapján szeretné csoportosítani az egyéneket, hozzon létre olyan szerepköröket, mint a Rendszergazda, a Fejlesztő, a Biztonsági rendszergazda és az Operátor.

• A munkafolyamatok naplózásának engedélyezése a konfiguráció átláthatóságának és nyomon követhetőségének, valamint a CI/CD-folyamatok egyéb módosításainak átláthatóságának és nyomon követhetőségének növelése érdekében.

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

• A támadási felület csökkentéséhez használjon olyan könnyű rendszerképeket, amelyek minimális operációs rendszer-lábnyommal rendelkeznek. Fontolja meg az olyan minimális képeket, mint az Alpine vagy a disztribúció nélküli képek, amelyek csak az alkalmazást és a hozzá tartozó futtatókörnyezetet tartalmazzák.

• Tárolók létrehozásakor csak megbízható alaprendszerképeket használjon. Kérje le ezeket az alaprendszerképeket egy magánregisztrációs adatbázisból, amely gyakran keres 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, amely elemzi a tárolólemezképek biztonsági réseit.

• A rendszerkép gyökérfelhasználói hozzáférésének vagy környezetének megakadályozása. Alapértelmezés szerint a tárolók gyökérként futnak.

  Fokozott biztonságot igénylő tárolók esetén fontolja meg egy AppArmor - vagy seccomp-profil használatát a Kubernetes-fürtön belül a futó tárolók biztonságának további kikényszerítéséhez.

Felépíté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 folyamatukba. A Teams úgy konfigurálja a folyamatokat, hogy a CI/CD platform biztonsági eszközei és bővítményei segítségével engedélyezze a biztonsági eljárásokat. Ezek a gyakorlatok közé tartozik a SAST, a szoftverösszetétel-elemzés (SCA) és a titkos kódok vizsgálata.

Ajánlott eljárás: A SAST végrehajtása az alkalmazás forráskódjában található potenciális 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 olyan funkció, amely a GitHub-adattárban lévő kódokat elemzi a biztonsági rések és kódolási hibák keresése érdekében. Megjeleníti a GitHub Enterprise Cloud problémáit.

  • 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.

  • Az ágszabályokat konfigurálhatja a szükséges állapot-ellenőrzésekhez. Az új kód egyesítése előtt például megkövetelheti, hogy a szolgáltatáságak naprakészek legyenek az alapággal. Ez a követelmény biztosítja, hogy az ágát a legújabb kóddal tesztelje.

  • Engedélyezze a Copilot Autofixnek , hogy fogadja az AI által létrehozott javításokat a kódkeresési riasztásokhoz. A Copilot Autofix közvetlenül a lekéréses kérelmekben javasolja a szervizelést, ami segít a fejlesztőknek a biztonsági megállapítások gyors megoldásában.

• A Kubernetes üzembehelyezési objektumainak elemzéséhez használjon olyan eszközöket, mint a kube-score . Ez az eszköz statikus kódelemzést végez a Kubernetes-objektumdefiníciókon. Megjeleníti a javaslatok listáját, hogy az alkalmazás biztonságosabbá és rugalmasabbá váljon.

Ajánlott eljárás: Titkos kódok vizsgálata a véletlenül lekötött titkos kódok észleléséhez

• Ha engedélyezi a titkos kódok vizsgálatát egy adattárban, a GitHub olyan mintákat keres a kódban, amelyek megfelelnek a sok 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 a Defender for Cloud titkos vizsgálattal é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.

  • Az Azure DevOpshoz készült Microsoft Biztonság DevOps bővítmény részeként titkos kódok vizsgálatát is futtathatja.

Ajánlott eljárás: 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 sebezhetőségének é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. Emellett információt nyújt a licencről, a függőkről és a függőségek koráról. A függőségek változásait egy lekéréses kérelem Fájlok módosított lapjának gazdag függvényén jeleníti meg.

• 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: SBOM létrehozása a konténerképekhez

• A szoftveres anyagjegyzék (SBOM) teljes leltárt nyújt a tárolólemezképeket alkotó összetevőkről, kódtárakról és függőségekről. Az SPDX- vagy a CycloneDX-jegyzék létrehozásához használjon olyan SBOM-generációs eszközöket, mint a Microsoft sbom-tool vagy a Syft a CI-build során.

• Csatoljon egy SBOM-t a Tárolóregisztrációs adatbázisban tárolt tárolórendszerképekhez, hogy lehetővé tegye az alsóbb rétegbeli biztonságirés-vizsgálat és a licencmegfelelés nyomon követését az ellátási láncban.

Ajánlott eljárás: IaC-sablonok vizsgálata a helytelen konfigurációk észleléséhez az üzembe helyezés előtt

• A felhőerőforrás-konfigurációk proaktív monitorozása a fejlesztési életciklus során.

• A DevOps-hoz készült Microsoft Defender támogatja a GitHub és az Azure DevOps-adattárakat is, és IaC-sablonokat vizsgálva azonosíthatja az IaC biztonsági réseit.

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óregiszter és az Amazon Elastic Container Registry (ECR) tárolóit, hogy értesítse Önt a képek ismert sebezhetőségeiről.

• Engedélyezheti, hogy az Azure Policy sebezhetőségi felmérést végezhessen a Container Registryben tárolt képeken, és részletes információkat nyújtson az egyes megállapításokról.

Ajánlott eljárás: Új rendszerképek automatikus létrehozása az alaprendszerkép-frissítésekhez

• A tárolóregisztrációs adatbázis feladatai dinamikusan felderítik az alaprendszerkép-függőségeket egy tárolólemezkép létrehozásakor. Amikor egy alkalmazásrendszerkép alaprendszerképének frissítését észleli, konfigurálhat egy buildelési feladatot, hogy automatikusan újraépítse az adott alaprendszerképre hivatkozó alkalmazásképeket.

Ajánlott eljárás: A Tárolóregisztrációs adatbázis, a Key Vault és a jelölés használatával digitálisan aláírhatja a tárolólemezképeket, és konfigurálhatja az AKS-fürtöt úgy, hogy csak érvényesített lemezképeket engedélyezzen

• A Key Vault tárolja a jelölési eszköz által használt aláírási kulcsokat. A Key Vault beépülő modul (azure-kv) hozzáfér ezekhez a kulcsokhoz a tárolólemezképek és egyéb összetevők aláírásához és ellenőrzéséhez. Ezeket az aláírásokat az Azure CLI-parancsok használatával csatolhatja a Container Registry-rendszerképekhez.

• Az aláírt konténerek biztosítják, hogy a telepítések megbízható forrásból származzanak, és hogy az artefaktumokat ne módosítsák a létrehozás után. 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.

  • Ratify ellenőrzi az összetevők biztonsági metaadatait, és érvényesíti a hozzáférési szabályokat a Kubernetes-fürtökre való üzembe helyezés előtt. Az AKS Image Integrity a Ratify-t használja beépített ellenőrzőként a képaláírások és az SBOM-igazolások igazolására, mielőtt a podok engedélyezése megtörténik a fürtbe.

Ü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 együttműködnek a CD-folyamatok megfelelő biztonsági vezérlőinek kialakításában. Ezek a vezérlők segítenek a kód éles környezetben történő biztonságos és automatizált üzembe helyezésében.

Ajánlott eljárás: Az üzembehelyezé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-e, vagy végrehajthatnak-e egy force push-t az ágra. Az ágba irányuló feltöltésekre vonatkozó követelményeket is beállítanak, például állapotellenőrzéseket vagy lineáris véglegesítési előzményt.

• Környezetek használata az üzembe helyezés során a védelmi szabályok és titkok konfigurálásához.

• A jóváhagyási és kapufunkcióval szabályozhatja az üzembe helyezési folyamat munkafolyamatát. Az éles környezetben való üzembe helyezés előtt például manuális jóváhagyást kérhet egy biztonsági vagy üzemeltetési csapattól.

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

• Az OpenID Connect (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.

• A CI/CD és a GitOps lekérés-alapú megközelítésének segítségével a biztonsági hitelesítő adatokat át tudja helyezni a Kubernetes-fürtjére. Ez a módszer 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özrő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: A 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 a Kubernetes Azure Policy bővítményét.

• Konfigurálja az Azure Policy for Kubernetes-et úgy, hogy a tárolólemezképek üzembe helyezését megbízható adatbázisokra korlátozza.

Üzemeltetési fázis

Ebben a fázisban műveletfigyelési és biztonsági monitorozási feladatokat hajthat végre a potenciális biztonsági incidensek proaktív monitorozása, elemzése és riasztása érdekében. A gyártási megfigyelhetőségi eszközök, mint az Azure Monitor és a Microsoft Sentinel, használatával figyelemmel kísérheti és biztosíthatja, hogy megfeleljen a vállalati biztonsági szabványoknak.

Ajánlott eljárás: A Defender for Cloud használata az éles konfigurációk automatikus vizsgálatához és monitorozásához

• 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 a Defender for Cloud tárolójavaslatait ( a Számítás és alkalmazások területen). A Defender for Cloud megjeleníti az irányítópultján található konfigurációs problémákat vagy biztonsági réseket.

  • Használja a Defender for Cloud szolgáltatást, és kövesse a hálózatvédelmi ajánlásait az AKS-fürt hálózati erőforrásainak védelméhez.

• Végezzen biztonságirés-felmérést a Container Registryben tárolt képekről.

  • A Tárolóregisztrációban futó rendszerképek folyamatos vizsgálatát a Defender for Containers engedélyezésével valósíthatja meg.

A legjobb gyakorlat: Tartsd naprakészen a Kubernetes-fürtöket.

• A Kubernetes gyakran ad ki új verziókat. Tartson fenn egy életciklus-kezelési stratégiát a fürtök támogatottságának és naprakészségének fenntartásához. Az AKS eszközöket biztosít a fürtfrissítések kezeléséhez. Az AKS tervezett karbantartási funkcióival szabályozhatja, hogy mikor történnek karbantartási időszakok és frissítések.

• Frissítse gyakran az AKS munkavégző csomópontokat. Az Azure heti operációs rendszer- és futtatókörnyezet-frissítéseket ad ki. Ezeket a frissítéseket felügyelet nélküli módban vagy manuálisan, az Azure CLI-vel automatikusan alkalmazhatja a további vezérlés érdekében.

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

• Az AKS-hez készült Azure Policy bővítmény telepítése után egyéni szabályzatdefiníciókat vagy szabályzatdefiníciók csoportjait, azaz kezdeményezéseket vagy szabályzatkészleteket 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 a külső IP-címek engedélyezési listára való korlátozásának megakadályozása. Egyéni szabályzatokat is létrehozhat adott használati esetekhez.

• Alkalmazza a szabályzati definíciókat a fürtre, és ellenőrizze, hogy az Azure Policy érvényesíti-e ezeket a hozzárendeléseket.

• A Gatekeeper használatával konfigurálhat egy olyan engedélyező vezérlőt, amely engedélyezi vagy megtagadja a telepítéseket 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.

  • Használja a Cilium által üzemeltetett Azure CNI-t hálózati házirendmotorként. A Cilium eBPF alapú adatsíkot használ, és támogatja a Kubernetes-specifikus szabályzatokat, a réteg-7 szabályzatokat és az FQDN-ek szűrését.

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. Prometheus-metrikákat gyűjthet a Prometheushoz készült Azure Monitor felügyelt szolgáltatáson keresztül, lekérdezheti a tároló- és platformnaplókat a Log Analyticsben, és megjelenítheti a fürt állapotát az Azure Managed Grafana-irányítópultokon keresztül.

  • Az Azure Monitor kiterjeszti a folyamatos monitorozást a kiadási folyamatokra. A monitorozási adatok használatával jóváhagyhatja vagy visszaállíthatja a kiadásokat. Az Azure Monitor biztonsági naplókat és riasztásokat is fogad a gyanús tevékenységekről.

  • Az AKS-példányokat csatlakoztassa az Azure Monitorhoz, és konfigurálja a fürt diagnosztikai beállításait.

    További információ: Azure biztonsági alapkonfiguráció az AKS-hez.

Ajánlott eljárás: A Defender for Cloud használata aktív fenyegetésfigyeléshez

• A Defender for Cloud aktív fenyegetésfigyelést biztosít az AKS-hez a csomópont szintjén (virtuálisgép-fenyegetések) és a fürt számítási feladataihoz.

• A DevOps-hoz készült Defender használatával átfogóan áttekintheti az összes CI/CD-folyamatot. Központi irányítópultot biztosít a biztonsági és operátori csapatoknak. Ez a központosított láthatóság 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 Vault Defender szokatlan és gyanús kísérleteket észlel a Key Vault-fiókok elérésére, és konfiguráció alapján riasztásokat küldhet 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

• Az AKS diagnosztikai naplóit csatlakoztassa a Microsoft Sentinelhez a minták és szabályok alapján történő központosított biztonsági monitorozáshoz. A Microsoft Sentinel adatösszekötőkkel teszi lehetővé ezt a hozzáférést.

Ajánlott eljárás: Az audit naplózás engedélyezése a produkciós klaszterek tevékenységeinek figyelésére

• 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 ki hajtotta végre az erőforrásokon végzett műveleteket.

• Engedélyezze a tartománynévrendszer (DNS) lekérdezésnaplózását dokumentált konfiguráció alkalmazásával a CoreDNS egyéni konfigurációtérképen.

• 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 ID-vel. Hozzon létre diagnosztikai beállításokat a Microsoft Entra-azonosítóhoz, és küldje el a naplózási és bejelentkezési naplókat egy Log Analytics-munkaterületre. A Log Analytics-munkaterületen konfigurálja a biztonsági eseményekre vonatkozó riasztásokat, például az inaktivált fiókokból való bejelentkezési kísérleteket.

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

• Engedélyezze az Azure-diagnosztikát a számítási feladat összes erőforrásában, hogy hozzáférjen a részletes diagnosztikai és naplózási információkat biztosító platformnaplókhoz. Ezeket a naplókat betöltheti a Log Analyticsbe vagy egy SIEM-megoldásba, például a Microsoft Sentinelbe biztonsági monitorozáshoz és riasztáshoz.

Közreműködők

A Microsoft fenntartja ezt a cikket. A következő közreműködők írták ezt a cikket.

Fő szerző:

• Adnan Khan | Sr. Cloud Solution Architect

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

• Ayobami Ayodeji | Program menedzser 2
• Ahmed Bham | Sr. Cloud Solution Architect
• Chad Kittel | Fő szoftvermérnök – Azure-minták és gyakorlatok
• John Poole | Sr. Cloud Solution Architect
• Bahram Rushenas | Sr. Megoldástervező
• Abed Sau | Sr. Cloud Solution Architect

A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.

Következő lépések

• Defender tárolókhoz
• A DevOps biztonságossá tétele
• Biztonság a DevOpsban (DevSecOps)
• GitHub Speciális biztonság

Kapcsolódó erőforrások

• GitOps
• DevSecOps for IaC
• Shift balra