A PCI-DSS 3.2.1 AKS-szabályozott fürt architektúrája (9. rész)

Ez a cikk egy olyan Azure Kubernetes Service- (AKS-) fürt referenciaarchitektúráját ismerteti, amely számítási feladatot futtat a Payment Card Industry Data Security Standard (PCI-DSS 3.2.1) szabványnak megfelelően. Ez az architektúra az infrastruktúrára összpontosít, nem a PCI-DSS 3.2.1 számítási feladatra.

Ez a cikk egy sorozat része. Olvassa el a bevezetést.

A javaslatok és példák ebből a kísérő referencia-megvalósításból származnak:

GitHub: Az Azure Kubernetes Service (AKS) alapfürtje a szabályozott számítási feladatokhoz bemutatja a szabályozott infrastruktúrát. Ez az implementáció mikroszolgáltatás-alkalmazást biztosít. Ez segít az infrastruktúra megismerésében, valamint a hálózati és biztonsági vezérlők szemléltetésében. Az alkalmazás nem jelent vagy implementál tényleges PCI DSS-számítási feladatot.

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

Ez a hálózati architektúra egy küllős topológián alapul. A központi virtuális hálózat tartalmazza a kimenő forgalom szabályozására szolgáló tűzfalat, a helyszíni hálózatok átjáró forgalmát, valamint egy harmadik hálózatot az SRE -hez (helymegmegerősítési mérnök) tartozó fürthozzáférést. Két küllős virtuális hálózat van. Egy küllő tartalmazza az AKS-fürtöt, amely a kártyatulajdonosi környezet (CDE) összetevője, és a PCI DSS számítási feladatát üzemelteti. A másik küllő virtuálisgép-rendszerképeket készít a környezethez való szabályozott SRE-hozzáféréshez.

Összetevők

Íme az architektúra fő összetevői. Ha nem ismeri ezeket a szolgáltatásokat, tekintse meg a kapcsolódó Azure-szolgáltatásokat a termékdokumentációra mutató hivatkozásokért.

Azure Firewall

A tűzfalpéldány védi a kimenő hálózati forgalmat. E biztonsági réteg nélkül a folyamat egy rosszindulatú külső szolgáltatással kommunikálhat, amely bizalmas vállalati adatokat képes kiszűrni.

Azure Bastion

Az alaparchitektúra egy alhálózatot biztosított az Azure Bastion számára, de nem építi ki az erőforrást. Ez az architektúra hozzáadja az Azure Bastiont az alhálózathoz, és biztonságos hozzáférést biztosít a jump boxhoz.

Azure Image Builder

Egy külön virtuális hálózaton kiépített virtuálisgép-rendszerképeket hoz létre alapszintű biztonsággal és konfigurációval. Ebben az architektúrában a rendszer úgy van testre szabva, hogy biztonságos csomópontrendszerképeket hozzon létre olyan felügyeleti eszközökkel, mint az Azure CLI és kubectla Flux CLI előre telepítve.

Azure-beli virtuálisgép-méretezési csoportok jump box-példányokhoz

A küllős hálózat további számítással rendelkezik a jump boxhoz. Ez a méretezési csoport az AKS-fürt eszközeinek futtatására szolgáló szabályozott hozzáférési pont, például kubectlszükség szerint.

Azure-alkalmazás átjáró integrált webalkalmazási tűzfallal (WAF)

Azure-alkalmazás átjáró terheléselosztása a 7. rétegben. A WAF biztosítja a bejövő forgalmat a gyakori webes forgalommal szembeni támadásoktól. A példány nyilvános előtérbeli IP-konfigurációval rendelkezik, amely felhasználói kéréseket fogad.

Azure Kubernetes Service (AKS)

Az üzemeltetési infrastruktúra, amely a kártyatulajdonosi adatkörnyezet (CDE) kulcsfontosságú része. Az AKS-fürt privát fürtként van üzembe helyezve. A Kubernetes API-kiszolgáló tehát nem érhető el a nyilvános interneten, az API-kiszolgáló felé irányuló forgalom pedig a magánhálózatra korlátozódik.

ACR-feladatok

Lehetővé teszi a tárolólemezképek létrehozásának és karbantartásának automatizált módját.

Azure Key Vault

Tárolja és kezeli a fürtműveletekhez szükséges titkos kulcsokat, például a tanúsítványokat és a titkosítási kulcsokat.

Fürtkonfiguráció

Íme néhány jelentős változás az alaparchitektúra szempontjából:

Csomópontkészlet szegmentálása

Ebben az architektúrában a fürt két felhasználói csomópontkészlettel és egy rendszercsomópontkészlettel rendelkezik. A csomópontkészletek számítási választása változatlan marad. Minden csomópontkészlet egy dedikált alhálózatban található, amely további hálózati elkülönítési határt biztosít a számítási szintek között.

A PCI-DSS 3.2.1 megköveteli a PCI-számítási feladatok elkülönítését más számítási feladatoktól a műveletek és a kapcsolatok szempontjából.

• Hatókörön belül: A PCI-számítási feladat, a környezet, amelyben található, és a műveletek.

• Hatókörön kívüli: Egyéb számítási feladatok, amelyek megoszthatják a szolgáltatásokat, de elkülönítve vannak a hatókörön belüli összetevőktől.

A legfontosabb stratégia a szükséges elkülönítési szint biztosítása. Az előnyben részesített módszer a hatókörön belüli és a hatókörön kívüli összetevők üzembe helyezése külön fürtökben. A lefelé irányuló oldal növeli a hozzáadott infrastruktúra költségeit és a karbantartási többletterhelést. Ez az implementáció közösen megkeresi a megosztott fürtök összes összetevőjét az egyszerűség kedvéért. Ha a modell követését választja, használjon szigorú fürtön belüli szegmentálási stratégiát. Függetlenül attól, hogy hogyan tartja fenn az elkülönítést, vegye figyelembe, hogy a megoldás fejlődésével egyes hatókörön kívüli összetevők hatókörön belülivé válhatnak.

A referencia-implementációban a második megközelítés az egyetlen fürtön üzembe helyezett mikroszolgáltatás-alkalmazással van bemutatva. A hatókörön belüli és a hatókörön kívüli számítási feladatok két külön felhasználói csomópontkészletben vannak szegmentálva. Az alkalmazás két szolgáltatáskészlettel rendelkezik; Az egyik készlet hatókörön belüli podokkal rendelkezik, a másik pedig hatókörön kívüli. Mindkét csoport két felhasználóicsomópont-készlet között oszlik meg. A Kubernetes-tárolók használatával a hatókörön belüli és a hatókörön kívüli podok külön csomópontokra vannak üzembe helyezve, és soha nem osztanak meg csomóponti virtuális gépet vagy hálózati IP-helyet.

Bemeneti vezérlő

A fürtön belüli Kubernetes bejövőforgalom-vezérlő NGINX-re módosult. Az alaparchitektúra a Traefiket használta. Ez a módosítás azt szemlélteti, hogy ez az összetevő a számítási feladatok követelményei alapján módosítható.

Privát Kubernetes API-kiszolgáló

Az alaparchitektúra nyilvános módban telepítette az AKS-fürtöt. Ez azt jelenti, hogy az AKS által felügyelt Kubernetes API-kiszolgálóval folytatott összes kommunikáció a nyilvános interneten keresztül történik. Ez ebben az architektúrában nem elfogadható, mert a PCI-DSS 3.2.1 tiltja a nyilvános kitettséget a rendszerösszetevőknek. Ebben a szabályozott architektúrában a fürt privát fürtként van üzembe helyezve. A Kubernetes API-kiszolgáló felé történő hálózati forgalom a magánhálózatra korlátozódik. Az API-kiszolgáló egy privát végponton keresztül érhető el a fürt hálózatában. A biztonság tovább bővül a hálózati biztonsági csoportok és más beépített funkciók használatával. Ezeket a hálózati konfiguráció ismerteti.

Podbiztonság

A számítási feladat biztonsági igényeinek leírásakor használja a tárolók megfelelő securityContext beállításait. Ide tartoznak az olyan alapvető beállítások, mint például fsGroupa ,runAsGrouprunAsUser / és a hamis (hacsak nem kötelező) beállítás.allowPrivilegeEscalation Legyen egyértelmű a Linux-képességek definiálásával és eltávolításával, valamint a SELinux-beállítások seLinuxOptionsdefiniálásával kapcsolatban.

Ne hivatkozzon képekre a címkék alapján az üzembehelyezési jegyzékekben. Ehelyett használja a tényleges képazonosítót. Így megbízhatóan leképezheti a tárolóvizsgálat eredményeit a fürtben futó tényleges tartalommal. Az Azure Policy használatával kényszerítheti, hogy a rendszerkép neve szerepeljen a képazonosító mintájában az engedélyezett reguláris kifejezésben. A Dockerfile FROM utasítás használatakor is kövesse ezt az útmutatást.

Hálózatkezelési konfiguráció

A küllők mindegyike külön virtuális hálózatokban van üzembe helyezve, amelyek mindegyike a saját címterükben található. Alapértelmezés szerint nem engedélyezett forgalom két virtuális hálózat között. A hálózaton belül a szegmentálást alhálózatok létrehozásával alkalmazza a rendszer.

A különböző Azure-szolgáltatások és funkciók, valamint a natív Kubernetes-szerkezetek kombinációja biztosítja a szükséges vezérlési szintet. Az alábbiakban néhány beállítást használunk ebben az architektúrában.

Alhálózati biztonság hálózati biztonsági csoportokon (NSG-k) keresztül

Számos NSG szabályozza a fürtbe és a fürtből való ki- és beáramlást. Íme néhány példa:

• A fürtcsomópont-készletek dedikált alhálózatokban vannak elhelyezve. Minden alhálózat esetében vannak olyan NSG-k, amelyek blokkolják a csomóponti virtuális gépekhez való SSH-hozzáférést, és engedélyezik a virtuális hálózatról érkező forgalmat. A csomópontkészletekből érkező forgalom a virtuális hálózatra korlátozódik.

• Az internetről érkező összes bejövő forgalmat a Azure-alkalmazás Gateway elfogja. Az NSG-szabályok például a következőt biztosítják:

  • Csak HTTPS-forgalom engedélyezett.
  • Az Azure Control Planeből érkező forgalom engedélyezett. További információ: Hozzáférés engedélyezése néhány forrás IP-címhez.

• Az Azure Container Registry-ügynökökkel rendelkező alhálózatokon az NSG-k csak a szükséges kimenő forgalmat teszik lehetővé. A forgalom például engedélyezett az Azure Key Vault, a Microsoft Entra ID, az Azure Monitor és más szolgáltatások felé, amelyekkel a tárolóregisztrációs adatbázisnak beszélnie kell.

• A jump boxot tartalmazó alhálózat felügyeleti műveletekhez készült. Az NSG-szabály csak az Azure Bastionból engedélyezi az SSH-hozzáférést a központban, és korlátozott kimenő kapcsolatokat. A jump boxok nem rendelkeznek univerzális internet-hozzáféréssel, és az NSG alhálózaton és az Azure Firewallon is vezérelve vannak.

A számítási feladatok, a rendszerbiztonsági ügynökök és más összetevők üzembe helyezésekor adjon hozzá további NSG-szabályokat, amelyek segítenek meghatározni az engedélyezett forgalom típusát. A forgalom nem lépi át az alhálózat határait. Mivel minden csomópontkészlet a saját alhálózatában található, figyelje meg a forgalmi mintákat, majd alkalmazzon pontosabb szabályokat.

Podok közötti biztonság hálózati házirendekkel

Ez az architektúra a lehető legnagyobb mértékben megpróbálja implementálni a Microsoft "nulla megbízhatóság" alapelveit.

A Teljes felügyelet hálózatok mint fogalom példákat mutatnak be a felhasználók által megadott névterek implementálásában a0005-i a0005-o. Minden számítási feladatnévtér esetében korlátozó NetworkPolicy-t kell alkalmazni. A szabályzatdefiníciók az ezekben a névterekben futó podoktól függenek. Győződjön meg arról, hogy a Log Analytics-ügynök által gyűjtött metrikákra vonatkozó felkészültséget, élő vonalakat és indítási mintavételeket számolja el. Fontolja meg a portok egységesítését a számítási feladatok között, hogy konzisztens NetworkPolicy- és Azure Policy-szabályzatot biztosíthasson az engedélyezett tárolóportokhoz.

Bizonyos esetekben ez nem praktikus a fürtön belüli kommunikációhoz. Nem minden felhasználó által megadott névtér használhat nulla megbízhatósági hálózatot (például cluster-baseline-settings nem használhat egyet).

TLS-titkosítás

Az alaparchitektúra TLS-titkosított forgalmat biztosít, amíg a fürt bejövőforgalom-vezérlője nem, de a pod-pod kommunikációja tiszta. Ebben az architektúrában a TLS a podok között történő forgalomra terjed ki, hitelesítésszolgáltatói (CA) ellenőrzéssel. Ezt a TLS-t egy szolgáltatásháló biztosítja, amely az mTLS-kapcsolatokat és az ellenőrzést kényszeríti ki a kommunikáció engedélyezése előtt.

Az implementáció mTLS-t használ. Az mTLS-támogatás szolgáltatáshálóval vagy anélkül is implementálható. Ha hálót használ, győződjön meg arról, hogy kompatibilis az Ön által választott tanúsítványkibocsátóval. Ez az implementáció Open Service Mesh-t használ.

Az implementáció bejövőforgalom-vezérlője helyettesítő tanúsítvány használatával kezeli az alapértelmezett forgalmat, ha egy bejövő erőforrás nem tartalmaz egy adott tanúsítványt. Ez elfogadható lehet, de ha a szervezeti szabályzat nem engedélyezi helyettesítő tanúsítványok használatát, előfordulhat, hogy módosítania kell a bejövőforgalom-vezérlőt, hogy ne használjon helyettesítő tanúsítványt.

Az Azure Key Vault hálózati korlátozásai

Minden titkos kulcs, kulcs és tanúsítvány az Azure Key Vaultban van tárolva. A Key Vault kezeli a tanúsítványkezelési feladatokat, például a rotációt. A Key Vaulttal való kommunikáció az Azure Private Linken keresztül történik. A Key Vaulthoz társított DNS-rekord egy privát DNS-zónában van, így nem oldható fel az internetről. Bár ez növeli a biztonságot, bizonyos korlátozások vannak érvényben.

Azure-alkalmazás átjáró nem támogatja a HTTP-figyelő TLS-tanúsítványainak beszerzést a Private Linkkel közzétett Key Vault-példányokból. Az implementáció tehát hibrid modellben helyezi üzembe a Key Vaultot. Továbbra is a Private Linket használja az azt támogató kapcsolatokhoz, de nyilvános hozzáférést is biztosít az Application Gateway-integrációhoz. Ha ez a hibrid megközelítés nem megfelelő az üzembe helyezéshez, helyezze át a tanúsítványkezelési folyamatot az Application Gatewayre. Ez felügyeleti többletterhelést okoz, de a Key Vault-példány teljesen el lesz különítve. További információ:

• Azure-alkalmazás Átjáró és Key Vault integrációja
• Hozzon létre egy alkalmazásátjárót TLS-leállítással az Azure CLI használatával.

DDoS elleni védelem

Engedélyezze az Azure DDoS Network Protectiont egy olyan alhálózattal rendelkező virtuális hálózatokhoz, amelyek nyilvános IP-címmel rendelkező Application Gatewayt tartalmaznak. Ezzel védelmet nyújt az infrastruktúrának és a számítási feladatnak a tömeges csalárd kérésekkel szemben. Az ilyen kérések szolgáltatáskimaradást okozhatnak, vagy elfedhetnek egy másik egyidejű támadást. Az Azure DDoS jelentős költséggel jár, és általában sok olyan számítási feladaton amortizálódik, amelyek több IP-címet is lefednek. A hálózatkezelési csapattal együttműködve koordinálhatja a számítási feladatok lefedettségét.

Identitáshozzáférés-kezelés

Szerepkörök definiálása és hozzáférés-vezérlés beállítása a szerepkör követelményeinek megfelelően. A szerepkörök leképezése a Kubernetes-műveletekre olyan szűken, mint a gyakorlatban. Kerülje a több függvényre kiterjedő szerepköröket. Ha egy személy több szerepkört tölt be, rendelje hozzá az adott személyhez az egyenértékű feladatfüggvényekhez kapcsolódó összes szerepkört. Így még ha egy személy is közvetlenül felelős mind a fürtért, mind a számítási feladatért, hozza létre a Kubernetes-eket ClusterRoles , mintha külön személyek lennének. Ezután rendelje hozzá ezt az önálló egyéni szerepkört az összes releváns szerepkörhöz.

Minimalizálja az állandó hozzáférést, különösen a nagy hatású fiókok, például a fürttel folytatott SRE/Ops interakciók esetén. Az AKS-vezérlősík támogatja a Microsoft Entra ID Privileged Access Management (PAM) igény szerinti (JIT) és a feltételes hozzáférési szabályzatokat is, amelyek a létrehozott szabályok alapján további szükséges hitelesítési érvényesítési rétegeket biztosítanak a kiemelt hozzáféréshez.

A PowerShell feltételes hozzáférés konfigurálásának további részleteiért lásd: New-MgIdentityConditionalAccessPolicy, Get-MgIdentityConditionalAccessPolicy és Remove-MgIdentityConditionalAccessPolicy.

Disk encryption (Lemeztitkosítás)

Amikor inaktív adatok titkosítását tervezi, fontolja meg a tárolólemezeket, az AKS-ügynökcsomópont virtuális gépeit, az egyéb virtuális gépeket, valamint az ideiglenes és az operációs rendszer lemezeit.

Tárolólemezek

Alapértelmezés szerint az Azure Storage-lemezek inaktív állapotban vannak titkosítva a Microsoft által felügyelt kulcsokkal. Ha nem rövid élettartamú operációsrendszer-lemezeket használ, vagy adatlemezeket ad hozzá, javasoljuk, hogy az ügyfél által felügyelt kulcsokat használja a titkosítási kulcsok vezérléséhez. Titkosítás a tárolási rétegen kívül, és csak titkosított adatok írása a tárolóeszközbe. Győződjön meg arról is, hogy a kulcsok soha nem szomszédosak a tárolási réteggel.

További információ: Saját kulcsok (BYOK) használata Azure-lemezekkel.

Fontolja meg a BYOK használatát a fürttel esetlegesen interakcióba lépő többi lemezhez, például az Azure Bastion-fronted jump boxokhoz. Ha a BYOK lehetőséget választja, a virtuális gépek termékváltozata és a regionális rendelkezésre állás korlátozott lesz, mivel ez a funkció nem támogatott minden termékváltozatban vagy régióban.

Virtuálisgép-gazdagépek

Javasoljuk, hogy engedélyezze a titkosítási funkciót a gazdagépen. Ez titkosítja a virtuálisgép-gazdagépet és az ideiglenes operációs rendszert, illetve a virtuálisgép-gazdagépen gyorsítótárazott adatlemezeket. További információ a gazdagépalapú titkosítás virtuális gépek támogatásáról.

Ez a funkció a gazdagépalapú titkosítási funkcióval kiterjeszthető az AKS-ügynökcsomópontok virtuálisgép-gazdagépén tárolt adatokra. A BYOK-hoz hasonlóan ez a funkció korlátozhatja a virtuálisgép-termékváltozatot és a régióválasztást.

Ezeket a funkciókat az Azure Policy használatával kényszerítheti ki.

Fürt biztonsági mentései (állapot és erőforrások)

Ha a számítási feladat fürtön belüli tárolást igényel, robusztus és biztonságos folyamatokkal rendelkezik a biztonsági mentéshez és a helyreállításhoz. Fontolja meg az olyan szolgáltatásokat, mint az Azure Backup (Azure Disks és Azure Files esetén), a biztonsági mentéshez és a helyreállításhoz.PersistantVolumeClaim Vannak előnyei, ha a biztonsági mentési rendszer támogatja a natív Kubernetes-erőforrásokat. Kiegészítheti az elsődleges módszert, amely összeegyezteti a fürtöt egy jól ismert állapottal, a kritikus rendszer-helyreállítási technikák biztonsági mentési rendszerével. Segíthet például az eltérésészlelésben és a rendszerállapot időbeli változásainak katalogizálásában a Kubernetes erőforrásszintjén.

A biztonsági mentési folyamatoknak a fürtön belüli vagy kívüli biztonsági mentésben lévő adatokat kell osztályozniuk. Ha az adatok a PCI DSS 3.2.1 hatókörébe tartoznak, terjessze ki a megfelelőségi határokat a biztonsági mentés életciklusára és céljára, amely a fürtön kívül lesz. A biztonsági mentések támadási vektorok lehetnek. A biztonsági mentés tervezésekor vegye figyelembe a földrajzi korlátozásokat, a inaktív titkosítást, a hozzáférés-vezérlést, a szerepköröket és a felelősségeket, a naplózást, az élettartamot és a illetéktelen módosítás megelőzését.

A fürtön belüli biztonsági mentési rendszerek várhatóan magas jogosultságokkal futnak a műveletek során. Értékelje ki a biztonsági mentési ügynök fürtbe való beléptetésének kockázatát és előnyeit. Az ügynök képességei átfedésben vannak a fürt egy másik felügyeleti megoldásával? Mi a minimális eszközkészlet a feladat elvégzéséhez a támadási felület kibontása nélkül?

Az Azure Policy szempontjai

Az alkalmazott Azure-szabályzatok általában nem rendelkeznek számítási feladatokkal hangolt beállításokkal. A megvalósítás során a Kubernetes-fürt podjának biztonsági korlátozásaira vonatkozó szabványokat alkalmazunk a Linux-alapú számítási feladatok kezdeményezéséhez, ami nem teszi lehetővé a beállítások finomhangolását. Érdemes exportálni ezt a kezdeményezést, és testre szabni az értékeit az adott számítási feladathoz. Az összes Gatekeeper deny Azure-szabályzatot egyetlen egyéni kezdeményezésbe, az összes audit Azure-szabályzatot pedig egy másik kezdeményezésbe is belefoglalhatja. Ezzel kategorizálja a csak információkra vonatkozó szabályzatok műveleteit.

Érdemes lehet belevenni a szabályzatokat és gatekeeper-system a kube-system névtereket a naplózási szabályzatokba a jobb láthatóság érdekében. Ha ezeket a névtereket a megtagadási házirendekbe foglalja, az fürthibát okozhat egy nem támogatott konfiguráció miatt.

Az adattitkosítást azure policy-riasztások beállításával kényszerítheti. Kényszerítheti például a BYOK-ot egy olyan riasztással, amely észleli a fürterőforráson nem található diskEncryptionSetID fürtöket. Egy másik szabályzat képes észlelni, hogy a gazdagépalapú titkosítás engedélyezve van-e.agentPoolProfiles A referencia-implementáció nem használ lemezeket a fürtben, és az operációs rendszer lemeze rövid élettartamú. Mindkét példaszabályzat a biztonsági funkció emlékeztetőjeként van érvényben. A szabályzatok beállítása auditnem block.

Képek kezelése

Használjon disztribúció nélküli alaprendszerképeket a számítási feladatokhoz. Ezekkel a rendszerképekkel a biztonsági felület minimálisra csökken, mivel a rendszer eltávolítja a kiegészítő rendszerképeket, például a rendszerhéjakat és a csomagkezelőket. Az előny csökkenti a CVE találati arányát.

Az Azure Container Registry támogatja az Open Container Initiative (OCI) rendszerképformátum-specifikációjának megfelelő lemezképeket. Ez egy olyan beléptető vezérlővel együtt, amely támogatja az aláírások érvényesítését, biztosíthatja, hogy csak a titkos kulcsokkal aláírt képeket futtatja. Vannak olyan nyílt forráskódú megoldások, mint az SSE Connaisseur vagy az IBM Portieris, amelyek integrálják ezeket a folyamatokat.

Védje a tárolólemezképeket és más OCI-összetevőket, mert azok tartalmazzák a szervezet szellemi tulajdonát. Használjon ügyfél által felügyelt kulcsokat, és titkosítsa a regisztrációs adatbázisok tartalmát. Alapértelmezés szerint az adatok inaktív állapotban, szolgáltatás által felügyelt kulcsokkal vannak titkosítva, de az ügyfél által felügyelt kulcsokra néha szükség van a jogszabályi megfelelőségi szabványoknak való megfeleléshez. Tárolja a kulcsot egy felügyelt kulcstárolóban, például az Azure Key Vaultban. Mivel ön hozza létre és birtokolja a kulcsot, Ön felel a kulcs életciklusával kapcsolatos műveletekért, beleértve a rotációt és a felügyeletet. További információ: A beállításjegyzék titkosítása ügyfél által felügyelt kulccsal.

A Kubernetes API Server működési hozzáférése

Korlátozhatja a fürtön végrehajtott parancsokat anélkül, hogy szükségképpen ugrómezőkre épülő működési folyamatot építenek ki. Ha IAM-kapus informatikai automatizálási platformmal rendelkezik, használja az előre definiált műveleteket a műveletek típusának szabályozásához és naplózásához.

Ügynökök létrehozása

A folyamatügynököknek hatókörön kívülinek kell lenniük a szabályozott fürtön, mert a buildelési folyamatok fenyegetésvektorok lehetnek. Bár gyakran használják a Kubernetes-t rugalmas buildügynök-infrastruktúraként, ne futtassa ezt a folyamatot a szabályozott számítási feladatok futtatókörnyezetének határain belül. A buildügynököknek nem szabad közvetlen hozzáféréssel rendelkezniük a fürthöz. Például csak a buildügynökök számára biztosítson hálózati hozzáférést az Azure Container Registryhez a tárolólemezképek, a helm-diagramok stb. leküldéséhez. Ezután telepítse a GitOpson keresztül. Általános gyakorlat, hogy a buildelési és kiadási munkafolyamatoknak nem szabad közvetlen hozzáféréssel rendelkezniük a Kubernetes-fürt API-hoz (vagy azok csomópontjaihoz).

Figyelési műveletek

Fürtön belüli tevékenységek

A fürtön omsagent belüli podok kube-system a Log Analytics-gyűjtési ügynök. Telemetriát gyűjtenek, tárolókat stdout és stderr naplókat kapnak, és Prometheus-metrikákat gyűjtenek. A gyűjtemény beállításait a container-azm-ms-agentconfig.yaml ConfigMap fájl frissítésével hangolhatja. Ebben a referencia-implementációban a naplózás engedélyezve van az összes kube-system számítási feladaton. Alapértelmezés szerint kube-system ki van zárva a naplózásból. Győződjön meg arról, hogy a naplógyűjtési folyamatot úgy állítja be, hogy a költségcélok, az SRE hatékonysága a naplók áttekintésekor és a megfelelőségi igények között egyensúlyban legyen.

Biztonsági felügyelet

A Defender for Containers használata a Felhőhöz készült Microsoft Defender-ben a biztonsági javaslatok megtekintéséhez és szervizeléséhez, valamint a tárolóerőforrások biztonsági riasztásainak megtekintéséhez. Engedélyezze a Microsoft Defender-csomagokat, mivel azok a kártyatulajdonosi adatkörnyezet különböző összetevőire vonatkoznak.

A naplók integrálása az adatok hatékony áttekintéséhez, elemzéséhez és lekérdezéséhez. Az Azure számos lehetőséget kínál. Bekapcsolhatja az AKS diagnosztikai naplóit, és elküldheti őket az Azure Monitor részét képező Log Analytics-munkaterületre. Egy másik lehetőség az adatok integrálása biztonsági információk és eseménykezelési (SIEM) megoldásokba, például a Microsoft Sentinelbe.

A szabványnak megfelelően az összes Log Analytics-munkaterület 90 napos megőrzési időtartamra van beállítva. Fontolja meg a folyamatos exportálás beállítását a hosszabb távú tároláshoz. Ne tároljon bizalmas adatokat a naplóadatokban, és győződjön meg arról, hogy az archivált naplóadatokhoz való hozzáférésre ugyanazok a hozzáférési szintek vonatkoznak, mint a legutóbbi naplóadatokra.

A teljes perspektívát az Felhőhöz készült Microsoft Defender Vállalati előkészítési útmutatóban találja. Ez az útmutató a regisztrációval, a SIEM-megoldásokba irányuló adatexportálással, a riasztásokra való válaszadással és a munkafolyamat automatizálásával foglalkozik.

Kapcsolódó Azure-szolgáltatások

Az alábbi hivatkozások az architektúra néhány fő összetevőjének funkciódokumentációjára mutatnak.

• Azure Kubernetes Service (AKS)
• Azure Firewall
• Azure Bastion
• Azure Image Builder
• Azure Virtual Machine Scale Sets
• Azure-alkalmazás átjáró integrált webalkalmazási tűzfallal (WAF)
• Azure Container Registry-feladatok
• Azure Key Vault

Következő lépések

Telepítsen és tartson fenn egy tűzfalkonfigurációt a kártyatulajdonosok adatainak védelme érdekében. Ne használja a szállító által megadott alapértelmezett értékeket a rendszerjelszavakhoz és más biztonsági paraméterekhez.