Szabályozott AKS-fürt hálózatkezelésének konfigurálása a PCI-DSS 3.2.1-hez (9. rész)

Ez a cikk a Payment Card Industry Data Security Standard (PCI-DSS 3.2.1) szerint konfigurált Azure Kubernetes Service-fürt (AKS) hálózatkezelési szempontjait ismerteti.

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

A PCI-DSS 3.2.1 szabvány fő témája a biztonság. A küllős topológia természetes választás egy szabályozott hálózati környezet beállításához. Egyszerűbb olyan infrastruktúrát létrehozni, amely biztonságos kommunikációt tesz lehetővé. A hálózati vezérlők mindkét küllős hálózatban vannak elhelyezve, és a Microsoft nulla megbízhatósági modelljét követik. A vezérlők a lehető legkisebb jogosultsággal hangolhatók a forgalom védelméhez, és szükség szerint biztosítják a hozzáférést. Emellett számos részletes védelmi módszert is alkalmazhat, ha vezérlőket ad hozzá az egyes hálózati ugrásokhoz és rétegekhez.

Ha számítási feladatot üzemeltet egy Kubernetesben, nem elegendő a hagyományos hálózati szerkezetekre, például a tűzfalszabályokra támaszkodni. Vannak olyan Kubernetes-natív szerkezetek is, amelyek szabályozzák a fürt forgalmát, például az erőforrást NetworkPolicy . Javasoljuk, hogy tekintse meg a Kubernetes dokumentációját az izolált podokkal, valamint a bejövő és kimenő házirendekkel kapcsolatos alapvető fogalmak megismeréséhez.

Biztonságos hálózat és rendszerek létrehozása és karbantartása

1. követelmény – Tűzfalkonfiguráció telepítése és karbantartása a kártyatulajdonosok adatainak védelme érdekében

Az AKS szolgáltatás támogatása

Az AKS támogatja a fürt privát virtuális hálózatban való üzembe helyezését privát fürtként. A fürt és az AKS által felügyelt Kubernetes API-kiszolgáló közötti kommunikáció megbízható hálózaton keresztül történik. Privát fürt esetén az Azure Virtual Network, a Hálózati biztonsági csoport (NSG) és más beépített hálózati vezérlők segítségével biztonságossá teheti a teljes kártyaőrző adatkörnyezetet (CDE). Ez a konfiguráció tiltja az internet és a környezet közötti jogosulatlan nyilvános hozzáférést. Az ilyen fürtök kiépítésével kapcsolatos részletekért lásd : Privát Azure Kubernetes Service-fürt létrehozása.

Az Azure Firewall integrálható az AKS-sel, és korlátozhatja a fürt kimenő forgalmát, amely a CDE kulcsfontosságú összetevője. A konfiguráció egyszerűvé vált egy AKS FQDN-címkével. Az ajánlott folyamat az Azure Firewall használata az Azure Kubernetes Service (AKS) üzemelő példányainak védelmére szolgál.

Az AKS-fürtök nyilvános internet-hozzáférést igényelnek. Korlátozza az internet felé irányuló kimenő forgalmat az Azure Firewall és az NSG használatával a fürt alhálózatán. További információ: Fürtcsomópontok kimenő forgalmának szabályozása az Azure Kubernetes Service-ben (AKS).

Az AKS opcionálisan támogatja a HTTP-proxy definiálásának lehetőségét, amely további kimenő forgalomvezérléshez és a fürt figyeléséhez használható. A fürtcsomópontok a megadott HTTP-proxykonfigurációt használják a kimenő forgalom átirányításához. Emellett egy MutációWebhook regisztrálva van a proxyadatok podokba való beszúrásához a létrehozáskor, ezért ajánlott, hogy a számítási feladatok örököljék ugyanazokat a proxyadatokat. A podok felülírhatják a proxyadatokat, ezért ajánlott HTTP-proxyt használni az Azure Firewallon kívül.

Az AKS-fürtöket a NetworkPolicy beépülő modullal kell létrehozni. Az AKS-ben számos lehetőség közül választhat a Hálózati házirend beépülő modulhoz, például a Calicohoz, az Azure Network Policy Managementhez és a Ciliumhoz. A Calico hálózati szabályzatával használhatja a Kubenetet vagy az Azure CNI-t. Az Azure Network Policy Management esetében csak az Azure CNI-t használhatja (a Kubenetet nem). Az Azure és a Calico Network Policy beépülő modul is nyílt forráskód. A Project Calico szolgáltatással kapcsolatos további információkért tekintse meg az átfogó PCI-megoldás tanulmányát, amely az alábbi tűzfalkövetelmények közül sokra vonatkozik.

Az Ön feladatai

Követelmény	Feladatkörök
1.1. követelmény	Tűzfal- és útválasztókonfigurációs szabványok létrehozása és implementálása.
1.2. követelmény	Tűzfal- és útválasztó-konfigurációk létrehozása, amelyek korlátozzák a nem megbízható hálózatok és a kártyaőrző adatkörnyezetben lévő rendszerösszetevők közötti kapcsolatokat.
1.3. követelmény	Tiltsa meg a közvetlen nyilvános hozzáférést az internet és a kártyaőrző adatkörnyezet bármely rendszerösszetevője között.
1.4. követelmény	Telepítsen személyes tűzfalszoftvert vagy azzal egyenértékű funkciókat minden olyan hordozható számítástechnikai eszközre (beleértve a vállalati és/vagy alkalmazotti tulajdonú eszközöket), amelyek a hálózaton kívül csatlakoznak az internethez (például az alkalmazottak által használt laptopokra), és amelyek a CDE eléréséhez is használhatók.
1.5. követelmény	Győződjön meg arról, hogy a tűzfalak kezelésére vonatkozó biztonsági szabályzatok és működési eljárások minden érintett fél számára dokumentálva, használatban vannak és ismertek.

1.1. követelmény

Olyan tűzfal- és útválasztókonfigurációs szabványokat hozhat létre és implementál, amelyek a következőket tartalmazzák:

1.1.1. követelmény

Hivatalos folyamat a hálózati kapcsolatok jóváhagyására és tesztelésére, valamint a tűzfal- és útválasztó-konfigurációk módosításainak jóváhagyására és tesztelésére.

Az Ön feladatai

Ne implementálja manuálisan a konfigurációkat, például az Azure Portal vagy az Azure CLI közvetlen használatával. Javasoljuk, hogy az infrastruktúra mint kód (IaC) használatát használja. Az IaC használatával az infrastruktúra egy leíró modellen keresztül kezelhető, amely verziószámozási rendszert használ. Az IaC-modell minden alkalmazáskor ugyanazt a környezetet hozza létre. Az IaC gyakori példái a Bicep, az Azure Resource Manager-sablonok (ARM-sablonok) vagy a Terraform. Ha az IaC nem megoldás, rendelkezik egy jól dokumentált eljárással a tűzfalszabály-módosítások nyomon követésére, implementálására és biztonságos üzembe helyezésére. További részletek a 11.2. követelmény részeként találhatók.

Különböző hálózati vezérlők kombinációját kell használnia, beleértve az Azure Firewallt, a hálózati biztonsági csoportokat (NSG-ket) és a Kubernetes-erőforrást NetworkPolicy .

Csökkentse a hálózati vezérlők elérésére és módosítására jogosult személyek számát. Szerepkörök definiálása és a csapatok felelősségének egyértelmű meghatározása. Egy szervezet hálózati csapata például ellenőrzi az informatikai csapatok által beállított irányítási szabályzatok módosításait. Legyen egy kapus jóváhagyási folyamat, amely magában foglalja a felhasználókat és a folyamatokat a hálózati konfigurációk módosításainak jóváhagyásához. A folyamatnak tartalmaznia kell egy lépést az összes hálózati vezérlő teszteléséhez. Részletes dokumentációval rendelkezik, amely leírja a folyamatot.

1.1.2. követelmény

Jelenlegi hálózati diagram, amely azonosítja a kártyatulajdonos adatkörnyezete és más hálózatok közötti kapcsolatokat, beleértve a vezeték nélküli hálózatokat is

Az Ön feladatai

A dokumentáció részeként tartson fenn egy hálózati folyamatábrat, amely biztonsági vezérlőkkel jeleníti meg a bejövő és kimenő forgalmat. Ez magában foglalja a forgalom áramlását más hálózatok, beleértve a vezeték nélküli hálózat a CDE. A diagramnak a fürtön belüli folyamatokat is meg kell jelenítenie. A diagramokra meghatározott követelmények vonatkoznak, beleértve a behatolásérzékelők és az alkalmazott vezérlők megjelenítését is.

Ez a kép a referencia-megvalósítás hálózati diagramját mutatja be.

Töltse le a diagram Visio-fájlját.

1.1.2. ábra – Hálózati folyamat

A folyamat leírása a következő szakaszokban található.

Ha rendelkezik Azure Network Watcher-sel, megtekintheti egy Azure-beli virtuális hálózat topológiáját. Megtekintheti a virtuális hálózat összes erőforrását, a virtuális hálózat erőforrásaihoz társított erőforrásokat és az erőforrások közötti kapcsolatokat.

1.1.3. követelmény

Aktuális diagram, amely az összes kártyaőrző adatáramlást mutatja a rendszerek és hálózatok között.

Az Ön feladatai

A dokumentáció részeként tartalmazzon egy adatfolyam-diagramot, amely bemutatja, hogyan védik az adatokat inaktív és átvitel alatt.

A diagramnak be kell mutatnia, hogyan áramlik az adat a számítási feladatba és onnan, és milyen információkat ad át az egyik erőforrásból a másiknak. Győződjön meg arról, hogy a diagram naprakész. Adjon hozzá egy lépést a változáskezelési folyamat részeként az adatfolyam-diagram frissítéséhez.

Mivel ez az architektúra az infrastruktúrára és nem a számítási feladatra koncentrál, itt nem találtunk illusztrációkat.

1.1.4. követelmény

A tűzfalra vonatkozó követelmények minden internetkapcsolatnál, valamint bármely demilitarizált zóna (DMZ) és a belső hálózati zóna között.

Az Ön feladatai

Egyértelmű definícióval rendelkezik arról, hogy mi határozza meg a DMZ határát. A kártyaőrző adatkörnyezet (CDE) például egy tűzfallal, hálózati házirendekkel és egyéb vezérlőkkel védett DMZ-ben lehet. További információ: Cloud DMZ.

A PCI DSS-infrastruktúra esetében Ön a felelős a CDE biztonságossá tételéért hálózati vezérlők használatával a CDE-t tartalmazó hálózathoz való jogosulatlan hozzáférés letiltásához. A hálózati vezérlőket megfelelően kell konfigurálni egy erős biztonsági helyzethez, és az alábbiakra kell alkalmazni őket:

• Kommunikáció a fürtön belüli megosztott összetevők között.
• Kommunikáció a számítási feladat és a megbízható hálózatok egyéb összetevői között.
• Kommunikáció a számítási feladat és a nyilvános internet között.

Ez az architektúra különböző tűzfaltechnológiákat használ a CDE-t üzemeltető fürt felé és onnan mindkét irányban áramló forgalom vizsgálatához:

• Azure-alkalmazás Átjáró forgalmi útválasztóként, integrált webalkalmazási tűzfala (WAF) pedig a fürt bejövő (bejövő) forgalmának védelmére szolgál.

• Az Azure Firewall minden kimenő (kimenő) forgalom védelmére szolgál bármely hálózatról és alhálózatáról.

  A tranzakciós vagy felügyeleti műveletek feldolgozása során a fürtnek kommunikálnia kell a külső végpontokkal. Előfordulhat például, hogy a fürt megköveteli az AKS vezérlősíkkal való kommunikációt, az operációs rendszerekkel és a csomagfrissítési rendszerekkel való kommunikációt, és sok számítási feladat külső API-kkal kommunikál. Ezen interakciók némelyike HTTP-en keresztül történhet, és támadási vektoroknak kell tekinteni. Ezek a vektorok olyan emberközi támadás célpontjai, amelyek adatkiszivárgást eredményezhetnek. Ha tűzfalat ad hozzá a kimenő forgalomhoz, az csökkenti ezt a fenyegetést.

  Azt javasoljuk, hogy még a podok közötti kommunikáció is TLS-titkosított legyen. Ez a gyakorlat a referencia-implementációban a kölcsönös TLS -hitelesítés (mTLS) használatával jelenik meg.

• Az NSG-k hozzáadódnak a fürt és az infrastruktúra más összetevői közötti forgalom védelméhez. A referencia-implementációban például vannak NSG-k az alhálózaton olyan csomópontkészletekkel, amelyek blokkolják az SSH-hozzáférési kísérleteket. Csak a virtuális hálózaton belüli forgalom engedélyezett.

  Amikor összetevőket ad hozzá az architektúrához, fontolja meg további NSG-k hozzáadását, amelyek engedélyezik vagy letiltják a forgalomtípusokat az alhálózatok határain. Mivel minden csomópontkészlet egy dedikált alhálózatban található, a számítási feladat várt forgalmi mintái alapján alkalmazzon pontosabb szabályokat.

• A Kubernetes-objektumok NetworkPolicy a fürtön belüli kommunikáció szabályozására szolgálnak.

  Alapértelmezés szerint nincsenek korlátozások a podok közötti kommunikációra. Fürtön belüli kommunikációra kell alkalmaznia NetworkPolicy , kezdve egy nulla megbízhatóságú hálózattal, és szükség szerint meg kell nyitnia az útvonalakat. A referencia-implementáció bemutatja a nulla megbízhatóságú hálózatokat a névterekben és a0005-o a a0005-i névterekben. Minden névtér (kivéve kube-system, , gatekeeper-systemés más AKS által megadott névterek) korlátozó hálózati szabályzatokkal rendelkezik. A szabályzatdefiníció az ezekben a névterekben futó podoktól függ. Győződjön meg arról, hogy megnyitja a készenlét, az élő vonalak és az indítási mintavételek elérési útját. Nyissa meg a csomópontszintű metrikák küldésének oms-agent elérési útját is. Fontolja meg a portok szabványosítását a számítási feladatok között, hogy konzisztens NetworkPolicy és Azure Policyt biztosíthasson az engedélyezett tárolóportokhoz.

1.1.5. követelmény

A hálózati összetevők kezelésével kapcsolatos csoportok, szerepkörök és felelősségek leírása.

Az Ön feladatai

Meg kell adnia a hálózati folyamatok és az érintett összetevők vezérlőit. Az eredményként kapott infrastruktúra több hálózati szegmensből áll, amelyek mindegyike számos vezérlővel és célokkal rendelkező vezérlővel rendelkezik. Győződjön meg arról, hogy a dokumentáció teljes lefedettséggel rendelkezik, a hálózattervezéstől az összes alkalmazott konfigurációig. Tartalmaznia kell a tulajdonjog részleteit is, egyértelmű felelősségi körekkel és az ezekért felelős szerepkörökkel.

Például tudja, hogy ki felel az Azure és az internet közötti hálózatok védelmének szabályozásáért. Egy vállalatnál általában az informatikai csapat felel az Azure Firewall-szabályok, a webalkalmazási tűzfalszabályok, az NSG-k és más hálózati forgalom konfigurálásáért és karbantartásáért. Ők is felelősek lehetnek a nagyvállalati szintű virtuális hálózatért és alhálózat-kiosztásért, valamint az IP-címek tervezéséért.

A számítási feladatok szintjén a fürt operátora felelős a nulla megbízhatóság hálózati házirendeken keresztüli fenntartásáért. A felelősségi körök közé tartozhat az Azure vezérlősíkkal való kommunikáció, a Kubernetes API-k és a monitorozási technológiák.

Mindig egy mindent megtagadó stratégiával kezdjen. Csak üzleti igény vagy szerepkör igazolása esetén adjon engedélyt.

1.1.6. követelmény

Az összes engedélyezett szolgáltatás, protokoll és port üzleti indoklásának és jóváhagyásának dokumentációja, beleértve a nem biztonságosnak ítélt protokollokhoz implementált biztonsági funkciók dokumentációját.

Az Ön feladatai

Részletes dokumentációval rendelkezik, amely leírja a hálózati vezérlőkben használt szolgáltatásokat, protokollokat és portokat. Tiltsa le az összeset, kivéve a kifejezetten engedélyezett portokat. Dokumentálja az üzleti indoklást és a dokumentált biztonsági funkciókat, ha a nem biztonságos protokollok használatát nem lehet elkerülni. Íme néhány példa az Azure Firewall referencia-implementációjából. A tűzfalszabályoknak kizárólag a kapcsolódó erőforrásokra kell kiterjedniük. Vagyis csak bizonyos forrásokból érkező forgalom léphet meghatározott teljes tartománynév-célokra.

Íme néhány példa a forgalom engedélyezésére:

Szabály	Protokoll:Port	Forrás	Cél	Indoklás
Biztonságos kommunikáció engedélyezése a csomópontok és a vezérlősík között.	HTTPS:443	A fürtcsomópontkészletekhez rendelt engedélyezett IP-címtartományok	Az AKS vezérlősík FQDN-céljainak listája. Ez az AzureKubernetesService FQDN címkével van megadva.	A csomópontoknak hozzáférésre van szükségük a vezérlősíkhoz a felügyeleti eszközökhöz, az állapot- és konfigurációs információkhoz, valamint arról, hogy mely csomópontok méretezhetők.
Biztonságos kommunikáció engedélyezése a Flux és a GitHub között.	HTTPS:443	AKS-csomópontkészletek	github.com, api.github.com	A Flux egy külső integráció, amely a csomópontokon fut. Szinkronizálja a fürtkonfigurációt egy privát GitHub-adattárral.

1.1.7. követelmény

A tűzfal- és útválasztó-szabálykészletek legalább hathavonta történő felülvizsgálatának követelménye.

Az Ön feladatai

A hálózati konfigurációk és a hatókörrel rendelkező szabályok áttekintéséhez legalább hathavonta rendelkezik folyamatokkal. Ez biztosítja, hogy a biztonsági garanciák aktuálisak és érvényesek legyenek. Ellenőrizze, hogy áttekinti-e ezeket a konfigurációkat:

• Azure Firewall-szabályok.
• NSG-szabályok.
• Azure-alkalmazás átjáró- és WAF-szabályokat.
• Natív Kubernetes-hálózati szabályzatok.
• Tűzfalvezérlők a vonatkozó Azure-erőforrásokon. Ez az architektúra például egy olyan szabályt használ az Azure Container Registryben, amely csak privát végpontról engedélyezi a forgalmat.
• Az architektúrához hozzáadott egyéb hálózati vezérlők.

Ha az előző felülvizsgálat óta megszüntette a számítási feladatokat, vagy módosította a fürt konfigurációját, fontos ellenőrizni, hogy a szükséges tűzfal-kivételekre vagy NSG-szabályokra vonatkozó feltételezések továbbra is érvényesek-e.

1.2. követelmény

Tűzfal- és útválasztó-konfigurációk létrehozása, amelyek korlátozzák a nem megbízható hálózatok és a kártyaőrző adatkörnyezetben lévő rendszerösszetevők közötti kapcsolatokat.

Az Ön feladatai

Ebben az architektúrában az AKS-fürt a kártyaőrző adatkörnyezet (CDE) kulcsfontosságú összetevője. Határozottan javasoljuk, hogy a fürt magánfürtként legyen üzembe helyezve a fokozott biztonság érdekében. Privát fürtben az AKS által felügyelt Kubernetes API-kiszolgáló és a csomópontkészletek közötti hálózati forgalom privát. Az API-kiszolgáló egy privát végponton keresztül érhető el a fürt hálózatában.

Nyilvános fürtöt is választhat, de ez a kialakítás nem ajánlott szabályozott számítási feladatokat tartalmazó fürtök esetén. Az API-kiszolgáló megjelenik az interneten. A DNS-rekord mindig felderíthető lesz. Ezért olyan vezérlőkkel kell rendelkeznie, amelyek védik a fürt API-t a nyilvános hozzáféréstől. Ha nyilvános fürt használata szükséges, akkor az ajánlott módszer az, hogy a Kubernetes szerepköralapú hozzáférés-vezérlőivel (RBAC) szoros vezérlőkkel kell rendelkeznie, amelyeket az AKS engedélyezett IP-tartományai funkcióval párosítva korlátozhatja, hogy ki férhet hozzá az AKS API-kiszolgálóhoz. Ez a megoldás azonban nem ajánlott szabályozott számítási feladatokat tartalmazó fürtök esetén.

A kártyatulajdonosok adatainak (CHD) feldolgozásakor a fürtnek megbízhatónak és nem megbízhatónak ítélt hálózatokkal kell együttműködnie. Ebben az architektúrában a PCI-DSS 3.2.1 számítási feladat peremhálózatán lévő küllős hálózatok is megbízható hálózatoknak minősülnek.

A nem megbízható hálózatok a peremhálózaton kívüli hálózatok. A nem megbízható hálózatok a következők:

• A többi központ és küllő ugyanahhoz az infrastruktúrához tartozhat, de kívül esik a számítási feladatok szegélyén.
• A nyilvános internet.
• A vállalati hálózat.
• Más virtuális hálózatok az Azure-ban vagy más felhőplatformon.

Ebben az architektúrában a képszerkesztőt üzemeltető virtuális hálózat nem megbízható, mert nincs szerepe a CHD-kezelésben. A CDE és az ilyen hálózatok közötti interakciót a követelményeknek megfelelően biztosítani kell. Ezzel a privát fürttel virtuális hálózatokat, NSG-ket és más beépített funkciókat használhat a teljes környezet védelméhez.

A privát fürtökről további információt a Privát Azure Kubernetes Service-fürt létrehozása című témakörben talál.

1.2.1. követelmény

Korlátozza a kártyatulajdonosi adatkörnyezethez szükséges bejövő és kimenő forgalmat, és kifejezetten tiltsa le az összes többi forgalmat.

Az Ön feladatai

Az Azure-beli virtuális hálózatok tervezésük szerint nem érhetőek el közvetlenül a nyilvános internetről. Minden bejövő (vagy bejövő) forgalomnak egy köztes útválasztón kell áthaladnia. Alapértelmezés szerint azonban a hálózat összes összetevője elérheti a nyilvános végpontokat. Ezt a viselkedést letilthatja egy privát alhálózat konfigurálásával, vagy egy UDR használatával, amely az összes kimenő forgalmat tűzfalon keresztül küldi el. A kimenő (vagy kimenő) forgalmat explicit módon kell védeni, hogy csak biztonságos titkosításokat és TLS 1.2-s vagy újabb kódokat engedélyezzen.

• Azure-alkalmazás átjáró integrált WAF-ja elfogja az összes HTTP-bejövő forgalmat, és átirányítja a vizsgált forgalmat a fürtre.

  Ez a forgalom megbízható vagy nem megbízható hálózatokból származhat. Az Application Gateway a küllős hálózat alhálózatán van kiépítve, és egy NSG védi. Ahogy a forgalom befelé halad, a WAF-szabályok engedélyezik vagy elutasítják, az Application Gateway pedig a konfigurált háttérrendszerbe irányítja a forgalmat. Az Application Gateway például az ilyen típusú forgalom megtagadásával védi a CDE-t:

  • Minden olyan forgalom, amely nem TLS-titkosított.
  • A porttartományon kívüli forgalom az Azure-infrastruktúra vezérlősíkjának kommunikációjához.
  • A fürt belső terheléselosztótól eltérő entitásai által küldött állapotadat-mintavételi kérelmek.

• Az Azure Firewall az összes kimenő (kimenő) forgalom biztonságossá tételéhez használható megbízható és nem megbízható hálózatokról.

  Az Azure Firewall a központi hálózat egy alhálózatán van kiépítve. Az Azure Firewall egyetlen kimenő pontként való kényszerítéséhez a felhasználó által megadott útvonalakat (UDR-eket) használjuk azon alhálózatokon, amelyek képesek kimenő forgalmat generálni. Ide tartoznak a nem megbízható hálózatok alhálózatai, például a képszerkesztő virtuális hálózata. Miután a forgalom elérte az Azure Firewallt, a rendszer több hatókörű szabályt alkalmaz, amelyek lehetővé teszik, hogy az adott forrásokból érkező forgalom meghatározott célokra menjen.

  További információ: Az Azure Firewall használata az Azure Kubernetes Service (AKS) üzemelő példányainak védelméhez.

• Igény szerint HTTP-proxyt is használhat a kimenő (kimenő) forgalom figyeléséhez és védelméhez a fürttől a külső erőforrásokig.

  A tűzfal mellett előfordulhat, hogy egyes szervezetek HTTP-proxyt szeretnének használni, hogy további vezérlőkkel rendelkezzenek a kimenő forgalomon. Javasoljuk, hogy a felhasználó által megadott útvonalak továbbra is a tűzfalra lépjenek, és a kimenő forgalom korlátozása érdekében csak a HTTP-proxyra lépjen. Ezzel a beállítással, ha egy pod megpróbálja felülbírálni a proxyt, akkor a tűzfal továbbra is blokkolhatja a kimenő forgalmat.

  További információ: HTTP-proxy támogatása az Azure Kubernetes Service-ben.

Előfordulhat, hogy a fürtnek más szolgáltatásokhoz kell hozzáférnie a nyilvános interneten keresztül. Ha például külső kártevőirtó szoftvert használ, a vírusdefiníciókat le kell szereznie egy kiszolgálóról a nyilvános interneten keresztül.

Más Azure-szolgáltatások végpontjaival folytatott interakciók az Azure gerinchálózatán találhatók. Például a szokásos műveletek részeként a fürtnek tanúsítványokat kell lekérnie a felügyelt kulcstárolóból, lemezképeket kell lekérnie egy tárolóregisztrációs adatbázisból stb. Győződjön meg arról, hogy ezek az interakciók privátak és biztonságosak az Azure Private Link használatával.

A tűzfalszabályok és a magánhálózatok mellett a forgalmi folyamatok NSG-szabályokkal is védettek. Íme néhány példa ebből az architektúrából, ahol a CDE a forgalom megtagadásával védve van:

• A csomópontkészletekkel rendelkező alhálózatokon lévő NSG-k megtagadják a csomópontokhoz való SSH-hozzáférést. Győződjön meg arról, hogy rendelkezik a megfelelő időben történő segélyhívási hozzáférés folyamatával, miközben továbbra is fenntartja a mindent megtagadás elvét.
• A felügyeleti eszközök futtatására szolgáló jump boxot tartalmazó alhálózati NSG az Azure Bastion kivételével minden forgalmat tagad a központi hálózaton.
• Az Azure Key Vault és az Azure Container Registry privát végpontjaival rendelkező alhálózatokon lévő NSG-k a belső terheléselosztó és az Azure Private Linken keresztüli forgalom kivételével minden forgalmat megtagadnak.

1.2.2. követelmény

Az útválasztó konfigurációs fájljainak védelme és szinkronizálása.

Az Ön feladatai

Rendelkezik egy mechanizmussal a tényleges üzembe helyezett állapot és a kívánt állapot közötti eltérés észlelésére. Az infrastruktúra mint kód (IaC) kiváló választás erre a célra. A Bicep-fájlok vagy az Azure Resource Manager-sablonok (ARM-sablonok) például megőrzik a kívánt állapot rekordját.

Az üzembehelyezési eszközöket, például a Bicep-fájlokat, forrásvezéreltnek kell lenniük, hogy az összes módosítás előzményei legyenek. Adatokat gyűjthet az Azure-tevékenységnaplókból, az üzembehelyezési folyamat naplóiból és az Azure üzembe helyezési naplóiból. Ezek a források segítenek nyomon követni az üzembe helyezett eszközöket.

A fürtben a hálózati vezérlőknek, például a Kubernetes hálózati házirendjeinek is követnie kell a forrás által szabályozott folyamatot. Ebben a megvalósításban a Fluxot használják GitOps-operátorként. Fürtkonfigurációk, például hálózati szabályzatok szinkronizálása esetén a Git-előzmények és a Flux és AZ API-naplók együttes használata konfigurációs előzmények forrása lehet.

1.2.3. követelmény

Telepítse a peremhálózati tűzfalakat az összes vezeték nélküli hálózat és a kártyatulajdonos adatkörnyezete között, és konfigurálja ezeket a tűzfalakat a letiltáshoz, vagy ha a forgalom üzleti szempontból szükséges, csak a vezeték nélküli környezet és a kártyatulajdonos adatkörnyezete közötti engedélyezett forgalmat engedélyezze.

Az Ön feladatai

Az AKS-csomópontok és a csomópontkészletek nem lehetnek elérhetők vezeték nélküli hálózatokról. Emellett a Kubernetes API-kiszolgálóra irányuló kéréseket is le kell tagadni. Az összetevők hozzáférése engedélyezett és biztonságos alhálózatokra korlátozódik.

Általában korlátozza a küllős hálózat felé történő helyszíni forgalomhoz való hozzáférést.

1.3. követelmény

Tiltsa meg a közvetlen nyilvános hozzáférést az internet és a kártyaőrző adatkörnyezet bármely rendszerösszetevője között.

Az Ön feladatai

Az AKS-fürtcsomópontok készletei a virtuális hálózaton belül működnek, és el vannak különítve a nyilvános hálózatoktól, például az internettől. Az elkülönítés fenntartása azáltal, hogy megakadályozza a nyilvános IP-címek fürtcsomópontokhoz való társítását, és NSG-szabályokat alkalmaz a fürt alhálózataira, hogy meggyőződjön arról, hogy az internetes forgalom le van tiltva. Az ellenőrzött hozzáféréssel kapcsolatos információkért tekintse meg a DMZ szakaszt.

Az AKS-fürt rendszercsomópontkészletekkel rendelkezik, amelyek kritikus rendszer podokat üzemeltetnek. Még a felhasználói csomópontkészleteken is vannak podok, amelyek más, fürtműveletekben részt vevő szolgáltatásokat futtatnak. Előfordulhat például, hogy a podok a Fluxot futtatva szinkronizálják a fürtkonfigurációt egy GitHub-adattárral, vagy a bejövő forgalomvezérlővel, hogy a forgalmat a számítási feladat podjaihoz irányítják. A csomópontkészlet típusától függetlenül minden csomópontot védeni kell.

Egy másik kritikus rendszerösszetevő az API-kiszolgáló, amely natív Kubernetes-feladatok végrehajtására szolgál, például a fürt állapotának és konfigurációjának fenntartására. A privát fürtök használatának egyik előnye, hogy az API-kiszolgáló végpontja alapértelmezés szerint nem érhető el. A privát fürtökről további információt a Privát Azure Kubernetes Service-fürt létrehozása című témakörben talál.

A többi végponttal való interakciót is védeni kell. Ennek egyik módja a magánhálózaton keresztüli kommunikáció korlátozása. Kérje meg például, hogy a fürt lekérje a rendszerképeket az Azure Container Registryből egy privát hivatkozáson keresztül.

1.3.1. követelmény

Implementáljon egy DMZ-t, amely csak az engedélyezett nyilvánosan elérhető szolgáltatásokat, protokollokat és portokat biztosító rendszerösszetevőkre korlátozza a bejövő forgalmat.

Az Ön feladatai

Íme néhány ajánlott eljárás:

• Ne konfiguráljon nyilvános IP-címeket a csomópontkészlet csomópontjain.
• Az Azure Policy használatával győződjön meg arról, hogy a Kubernetes nem tesz közzé nyilvános terheléselosztót. A fürtön belüli forgalmat belső terheléselosztókon kell irányítani.
• Csak a waf-tal integrált Azure-alkalmazás Átjáró számára tegye elérhetővé a belső terheléselosztókat.
• A hálózati vezérlőknek adott esetben meg kell adniuk a forrásra, a célra, a portra és a protokollra vonatkozó korlátozásokat.
• Ne tegye elérhetővé az API-kiszolgálót az interneten. Amikor privát módban futtatja a fürtöt, a végpont nem lesz közzétéve, és a csomópontkészletek és az API-kiszolgáló közötti kommunikáció privát hálózaton keresztül történik.

A felhasználók szegélyhálózatot implementálhatnak az AKS-fürtök védelme érdekében. További információ: Cloud DMZ.

1.3.2. követelmény

A DMZ-n belüli IP-címekre irányuló bejövő internetes forgalom korlátozása.

Az Ön feladatai

A fürthálózaton legyen egy NSG az alhálózaton a belső terheléselosztóval. Konfigurálja a szabályokat úgy, hogy csak olyan alhálózati forgalmat fogadjanak el, amely Azure-alkalmazás WAF-tal integrált átjáróval rendelkezik. Az AKS-fürtben a Kubernetes NetworkPolicies használatával korlátozza a podokra irányuló bejövő forgalmat.

1.3.3. követelmény

Hamisítás elleni intézkedések implementálása a hamisított forrás IP-címek hálózatba való belépésének észlelésére és letiltására.

Azure-feladatok

Az Azure hálózatszűrést valósít meg a hamisított forgalom megakadályozása és a bejövő és kimenő forgalom megbízható platformösszetevőkre való korlátozása érdekében.

1.3.4. követelmény

Ne engedélyezze a jogosulatlan kimenő forgalmat a kártyatulajdonos adatkörnyezetéből az internetre.

Az Ön feladatai

Az alábbi módokon tilthatja le a jogosulatlan kimenő forgalmat:

• Az AKS-fürtből érkező összes kimenő forgalom kényszerítése az Azure Firewallon való áthaladáshoz felhasználó által megadott útvonalak (UDR-ek) használatával az összes fürtalhálózaton. Ide tartoznak a rendszer- és felhasználói csomópontkészletekkel rendelkező alhálózatok.
• A kimenő forgalom korlátozásához vegye fel az NSG-ket a csomópontkészletekkel rendelkező alhálózatokra.
• A Kubernetes NetworkPolicies használatával korlátozhatja a podok kimenő forgalmát.
• További szabályzatok kezeléséhez használjon szolgáltatáshálót. Ha például csak a podok közötti TLS-titkosított forgalmat engedélyezi, a szolgáltatásháló-proxy képes kezelni a TLS-ellenőrzést. Ezt a példát ebben a megvalósításban mutatjuk be. A meghatalmazott proxyként van üzembe helyezve.
• Tiltsa meg a nyilvános IP-címek hozzáadását a CDE hálózataihoz, kivéve, ha az alhálózatok kifejezetten engedélyezettek, például a tűzfal alhálózatai.
• Az Azure Firewall mellett HTTP-proxyval korlátozhatja az AKS-fürtből az internetre irányuló kimenő forgalmat.
• Az Azure Monitor Private Link Service (AMPLS) használatával a Container Insights naplóit biztonságos, privát kapcsolaton keresztül küldheti el az Azure Monitornak. Ismerje meg az AMPLS engedélyezésének hatását.

További információ: Fürtcsomópontok kimenő forgalmának szabályozása az Azure Kubernetes Service-ben (AKS).

1.3.5. követelmény

Csak "létrehozott" kapcsolatok engedélyezése a hálózathoz.

Azure-feladatok

Az Azure hálózatszűrést valósít meg a hamisított forgalom megakadályozása és a bejövő és kimenő forgalom megbízható platformösszetevőkre való korlátozása érdekében. Az Azure-hálózat elkülönítve van, hogy elkülönítse az ügyfélforgalmat a felügyeleti forgalomtól.

1.3.6. követelmény

Helyezze el a kártyaőrző adatokat (például adatbázist) tároló rendszerösszetevőket egy belső hálózati zónában, elkülönítve a DMZ-től és más nem megbízható hálózatoktól.

Az Ön feladatai

A tárolórendszereket csak magánhálózaton teheti elérhetővé, például a Private Link használatával. Emellett korlátozza a hozzáférést az azt igénylő csomópontkészlet-alhálózat(ok)ból. Tartsa az állapotot a fürtben és a saját dedikált biztonsági zónájában.

1.3.7. követelmény

Ne tegye közzé a magánhálózati IP-címeket és az útválasztási információkat jogosulatlan felek számára.

Az Ön feladatai

Ennek a követelménynek a teljesítéséhez a nyilvános AKS-fürtök nem választhatók. A privát fürtök privát DNS-zóna használatával tartják távol a DNS-rekordokat a nyilvános internettől. Nyilvános DNS-címmel azonban továbbra is létrehozhat privát AKS-fürtöt. Ezért javasoljuk, hogy explicit módon tiltsa le ezt a funkciót enablePrivateClusterPublicFQDN úgy, hogy false megakadályozza a vezérlősík magánhálózati IP-címének közzétételét. Fontolja meg az Azure Policy használatát a nyilvános DNS-rekordok nélküli privát fürtök használatának kényszerítéséhez.

Emellett használjon privát DNS-zónát az útválasztáshoz a WAF-hez integrált Azure-alkalmazás átjáróval rendelkező alhálózat és a belső terheléselosztóval rendelkező alhálózat között. Győződjön meg arról, hogy a HTTP-válaszok nem tartalmaznak privát IP-információt a fejlécekben vagy a törzsben. Győződjön meg arról, hogy az IP- és DNS-rekordokat tartalmazó naplók nem érhetők el a működési igényeken kívül.

A Private Linken keresztül csatlakoztatott Azure-szolgáltatások nem rendelkeznek nyilvános DNS-rekorddal, amely felfedi a magánhálózati IP-címeket. Az infrastruktúrának optimálisan kell használnia a Private Linket.

1.4. követelmény

Telepítse a személyes tűzfalszoftvert vagy azzal egyenértékű funkciókat minden olyan hordozható számítástechnikai eszközre, amely a hálózaton kívül csatlakozik az internethez, és amelyek a CDE eléréséhez is használhatók.

Az Ön feladatai

A privát fürtöt az AKS vezérlősíkja kezeli. Nincs hozzáférése közvetlenül a csomópontokhoz. A felügyeleti feladatok elvégzéséhez olyan felügyeleti eszközöket kell használnia, mint a kubectl egy külön számítási erőforrásból. A parancsok futtatásához használhat egy légkondenzált jump boxot. A jump boxból bejövő és kimenő forgalmat is korlátozni és biztonságossá kell tenni. Ha VPN-t használ a hozzáféréshez, győződjön meg arról, hogy az ügyfélszámítógépet vállalati szabályzat kezeli, és minden feltételes hozzáférési szabályzat érvényben van.

Ebben az architektúrában ez a jump box egy külön alhálózatban található a küllős hálózaton. A jump box bejövő hozzáférését egy olyan NSG-vel korlátozza, amely csak az Azure Bastionon keresztül engedélyezi az SSH-n keresztüli hozzáférést.

Ha bizonyos parancsokat szeretne futtatni a jump boxon, el kell érnie a nyilvános végpontokat. Például az Azure felügyeleti síkja által felügyelt végpontok. A kimenő forgalomnak biztonságosnak kell lennie. A küllős hálózat többi összetevőjéhez hasonlóan a jump boxból kimenő forgalom korlátozva van egy UDR használatával, amely arra kényszeríti a HTTPS-forgalmat, hogy áthaladjon az Azure Firewallon.

1.5. követelmény

Győződjön meg arról, hogy a tűzfalak kezelésére vonatkozó biztonsági szabályzatok és működési eljárások minden érintett fél számára dokumentálva, használatban vannak és ismertek.

Az Ön feladatai

Kritikus fontosságú, hogy a folyamatról és a szabályzatokról alapos dokumentációt tartson fenn. Ez különösen igaz az AKS-fürtöt szegmentált Azure Firewall-szabályok kezelésekor. A szabályozott környezeteket üzemeltető személyeket ki kell oktatni, tájékoztatni és ösztönözni kell, hogy támogassák a biztonsági garanciákat. Ez különösen fontos a széles körű rendszergazdai jogosultságokkal rendelkező fiókokkal rendelkező felhasználók számára.

2. követelmény – Ne használjon szállító által megadott alapértelmezett értékeket a rendszerjelszavakhoz és más biztonsági paraméterekhez

Az Ön feladatai

Követelmény	Feladatkörök
2.1. követelmény	A rendszer hálózati telepítése előtt mindig módosítsa a szállító által megadott alapértelmezett beállításokat, és távolítsa el vagy tiltsa le a szükségtelen alapértelmezett fiókokat.
2.2. követelmény	Konfigurációs szabványok fejlesztése az összes rendszerösszetevőhöz. Biztosíthatja, hogy ezek a szabványok minden ismert biztonsági rést elhárítanak, és összhangban vannak az iparág által elfogadott rendszermegerősítési szabványokkal.
2.3. követelmény	Az összes nem konzolos rendszergazdai hozzáférés titkosítása erős titkosítással.
2.4. követelmény	A PCI DSS hatókörébe tartozó rendszerösszetevők leltárának karbantartása.
2.5. követelmény	Győződjön meg arról, hogy a szállítói alapértelmezett értékek és egyéb biztonsági paraméterek kezelésére vonatkozó biztonsági szabályzatok és működési eljárások dokumentálva vannak, használatban vannak és ismertek az összes érintett fél számára.
2.6. követelmény	A megosztott tárhelyszolgáltatóknak védenie kell az egyes entitások üzemeltetett környezetét és kártyatulajdonosi adatait.

Ne használjon szállító által megadott alapértelmezett értékeket a rendszerjelszavakhoz és más biztonsági paraméterekhez

2.1. követelmény

A rendszer hálózati telepítése előtt mindig módosítsa a szállító által megadott alapértelmezett beállításokat, és távolítsa el vagy tiltsa le a szükségtelen alapértelmezett fiókokat.

Az Ön feladatai

A szállítók által megadott alapértelmezett beállításokat módosítani kell. Az alapértelmezett beállítások gyakori támadási vektorok, és a rendszer hajlamossá teszi a támadásokat. Íme néhány szempont:

• Tiltsa le a rendszergazdai hozzáférést a tárolóregisztrációs adatbázisban.
• Győződjön meg arról, hogy a jump boxok és a buildügynökök követik a felhasználókezelési eljárásokat, eltávolítva a szükségtelen rendszerfelhasználókat.
• Ne hozzon létre és ne biztosítson SSH-kulcshozzáférést a csomópontokhoz a rendszergazdai felhasználók számára. Ha vészhelyzeti hozzáférésre van szükség, az Azure helyreállítási folyamatával igény szerint férhet hozzá.

Azure-feladatok

A Microsoft Entra ID olyan jelszószabályzatokkal rendelkezik, amelyek a felhasználók által megadott új jelszavakra vannak kényszerítve. Ha módosít egy jelszót, a régebbi jelszó érvényesítésére van szükség. A rendszergazda által visszaállított jelszót módosítani kell, amikor a felhasználó legközelebb bejelentkezik.

2.1.1. követelmény

A kártyatulajdonosi adatkörnyezethez csatlakoztatott vagy kártyatulajdonosi adatokat továbbító vezeték nélküli környezetek esetében módosítsa a telepítés során a vezeték nélküli szállítók minden alapértelmezett beállítását, beleértve, de nem kizárólagosan az alapértelmezett vezeték nélküli titkosítási kulcsokat, jelszavakat és SNMP-közösségi sztringeket.

Az Ön feladatai

Ez az architektúra és az implementáció nem úgy van kialakítva, hogy a helyszíni vagy vállalati hálózatokat vezeték nélküli kapcsolaton keresztüli felhőtranzakciókra hajtsa végre. A szempontokat a PCI-DSS 3.2.1 szabvány hivatalos útmutatójában találhatja meg.

2.2. követelmény

Konfigurációs szabványok fejlesztése az összes rendszerösszetevőhöz.

Az Ön feladatai

Implementálja a javaslatokat a Microsoft felhőbiztonsági teljesítménymutatójában. Egyetlen, konszolidált áttekintést nyújt az Azure biztonsági ajánlásairól, amely olyan iparági keretrendszerekre terjed ki, mint a CIS, az NIST, a PCI-DSS 3.2.1 és más. Az Felhőhöz készült Microsoft Defender funkciók és az Azure Policy segítségével nyomon követheti a szabványokat. Az Azure biztonsági benchmark a Felhőhöz készült Microsoft Defender alapértelmezett kezdeményezése. Fontolja meg további automatizált ellenőrzések kiépítését az Azure Policyban és az Azure Tenant Security Solutionben (AzTS).

Dokumentálja a CDE összes összetevőjének kívánt konfigurációs állapotát, különösen az AKS-csomópontok, a jump box, a buildügynökök és a fürttel kommunikáló egyéb összetevők esetében.

További információ: Microsoft cloud security benchmark.

Az Azure felelőssége

Az Azure olyan biztonsági konfigurációs szabványokat biztosít, amelyek megfelelnek az iparág által elfogadott szigorítási szabványoknak. A szabványokat legalább évente felülvizsgálják.

2.2.1. követelmény

Kiszolgálónként csak egy elsődleges függvényt implementálhat, hogy megakadályozza azokat a függvényeket, amelyek eltérő biztonsági szinteket igényelnek ugyanazon a kiszolgálón. (Például a webkiszolgálók, adatbázis-kiszolgálók és DNS-kiszolgálókat külön kiszolgálókon kell implementálni.)

Az Ön feladatai

A legfontosabb stratégia a szükséges szegmentálási szint biztosítása. Ennek egyik módja 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. Ismerje meg, hogy ez megnöveli a hozzáadott infrastruktúra költségeit és a karbantartási többletterhelést. Egy másik módszer az összes összetevő közös megkeresése egy megosztott fürtben. Szegmentálási stratégiák használata az elkülönítés fenntartásához. Például külön csomópontkészletek vannak egy fürtben.

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. Az alkalmazás két szolgáltatáskészlettel rendelkezik: az egyik csoport hatókörön belüli podokkal, 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ópontkészletekre vannak üzembe helyezve, és soha nem osztanak meg csomóponti virtuális gépet.

A tárolótechnológiák esetében ez a szegmentálás alapértelmezés szerint azért van megadva, mert a tárolónak csak egy példánya felelős a rendszerben egy függvényért.

Minden számítási feladat podjának saját identitást kell használnia. Nem örökölhet fürtszintű vagy csomópontszintű identitást.

Ha lehetséges, használjon külső tárolót a csomóponton belüli (fürtön belüli) tároló helyett. A fürt podjait kizárólag olyan munkákhoz tartsa fenntartva, amelyeket a kártyatulajdonosok adatfeldolgozásának részeként kell elvégezni. Helyezze át a hatókörön kívüli műveleteket a fürtön kívülre. Ez az útmutató ügynökökre, nem kapcsolódó számítási feladatokra vagy olyan tevékenységekre vonatkozik, mint például egy jump box a fürtben.

2.2.2. követelmény

Csak a rendszer működéséhez szükséges szolgáltatásokat, protokollokat, démonokat stb. engedélyezze.

Az Ön feladatai

Mielőtt engedélyezené őket, tekintse át a funkciókat és a következményeket. Az alapértelmezett beállítások tartalmazhatnak olyan szolgáltatásokat, amelyekre nincs szüksége, és előfordulhat, hogy ezeknek a funkcióknak láthatóságra van szükségük a számítási feladatban. Erre példa a Azure-alkalmazás Gateway alapértelmezett SSL-házirendjének titkosítása. Ellenőrizze, hogy a szabályzat túlságosan megengedő-e. A javaslat az, hogy hozzon létre egy egyéni szabályzatot, ha csak a szükséges titkosításokat választja ki.

Az olyan összetevők esetében, amelyek teljes körű vezérléssel rendelkeznek, távolítsa el az összes szükségtelen rendszerszolgáltatást a rendszerképekből. Tekintse át például a képeket a jump boxok és az ügynökök létrehozásához, és távolítsa el a szükségtelen összetevőket.

Az olyan összetevők esetében, ahol csak láthatóságot biztosít, például AKS-csomópontokat, dokumentálja, hogy az Azure mit telepít a csomópontokra. DaemonSets Fontolja meg, hogy további naplózást biztosítson ezekhez a felhőalapú összetevőkhöz.

2.2.3. követelmény

További biztonsági funkciókat valósíthat meg minden olyan szükséges szolgáltatáshoz, protokollhoz vagy démonhoz, amely nem biztonságos.

Az Ön feladatai

Az Application Gateway integrált WAF-et használ, és egyezteti a nyilvános végpontjára küldött kérés TLS-kézfogását, így csak biztonságos titkosítást tesz lehetővé. A referencia-implementáció csak a TLS 1.2-t és a jóváhagyott titkosításokat támogatja.

Tegyük fel, hogy rendelkezik egy örökölt eszközzel, amelynek Azure-alkalmazás Átjárón keresztül kell kommunikálnia a CDE-vel. A követelmény teljesítéséhez az Application Gatewaynek engedélyeznie kell egy nem biztonságos protokollt. Dokumentálja ezt a kivételt, és figyelje, hogy a protokollt az örökölt eszközön kívül használják-e. Az örökölt interakció megszüntetése után azonnal tiltsa le ezt a protokollt.

Az Application Gateway nem válaszolhat a 80-as porton érkező kérelmekre. Ne végezzen átirányításokat az alkalmazás szintjén. Ez a referencia-implementáció rendelkezik egy NSG-szabálysal, amely blokkolja a 80-ás port forgalmát. A szabály az Application Gateway alhálózatán található.

Ha a fürtben lévő számítási feladatok nem tudják betartani a biztonsági megfelelőségi profilok vagy egyéb vezérlők (például korlátok és kvóták) köré vonatkozó szervezeti szabályzatot, győződjön meg arról, hogy a kivétel dokumentálva van. Figyelnie kell, hogy csak a várt funkciók legyenek végrehajtva.

2.2.4. követelmény

Konfigurálja a rendszerbiztonsági paramétereket a helytelen használat megakadályozása érdekében.

Az Ön feladatai

Az architektúrában használt összes Azure-szolgáltatásnak követnie kell a Microsoft felhőbiztonsági benchmarkjának ajánlásait. Ezek a javaslatok kiindulópontként szolgálnak adott biztonsági konfigurációs beállítások kiválasztásához. Hasonlítsa össze a konfigurációt az adott szolgáltatás alapkonfigurációjához. A biztonsági alapkonfigurációkkal kapcsolatos további információkért tekintse meg az Azure biztonsági alapkonfigurációit.

Az Open Policy Agent beléptető vezérlője az Azure Policyval együttműködve észleli és megakadályozza a fürt helytelen konfigurációit. Tegyük fel, hogy van egy szervezeti szabályzat, amely nem engedélyezi a nyilvános IP-foglalásokat a csomópontokon. Ilyen foglalás észlelésekor a rendszer naplózásra vagy elutasításra jelöli meg a szabályzatdefinícióban megadott művelet alapján.

Az infrastruktúra szintjén korlátozásokat alkalmazhat az Azure-erőforrások típusára és konfigurációjára. Az Azure Policy használatával megakadályozhatja a helytelen konfigurációkat. Ebben a referencia-implementációban van egy szabályzat, amely tagadja a nem privát AKS-fürtök létrehozását.

Győződjön meg arról, hogy minden kivételt rendszeresen dokumentál és ellenőriz.

Azure-feladatok

Az Azure többtényezős hozzáférés-vezérléssel és dokumentált üzleti igényekkel biztosítja, hogy csak a jogosult személyzet konfigurálhassa az Azure platform biztonsági vezérlőinek konfigurálását.

2.2.5. követelmény

Távolítsa el az összes szükségtelen funkciót, például szkripteket, illesztőprogramokat, funkciókat, alrendszereket, fájlrendszereket és szükségtelen webkiszolgálókat.

Az Ön feladatai

Ne telepítsen szoftvereket ugródobozokra vagy olyan ügynökökre, amelyek nem vesznek részt egy tranzakció feldolgozásában, vagy nem biztosítják a megfelelőségi követelmények, például a biztonsági ügynökök megfigyelhetőségét. Ez a javaslat a fürt entitásokra, például DaemonSet a podokra is vonatkozik. Győződjön meg arról, hogy az összes telepítést észleli és naplózza.

2.3. követelmény

Az összes nem konzolos rendszergazdai hozzáférés titkosítása erős titkosítással.

Az Ön feladatai

A fürthöz való rendszergazdai hozzáférést a konzol használatával kell elvégezni. Ne tegye elérhetővé a fürt vezérlősíkját.

Azure-feladatok

Az Azure biztosítja az erős titkosítás használatát a hipervizor-infrastruktúra elérésekor. Biztosítja, hogy az Azure Portalt használó ügyfelek erős titkosítással férhessenek hozzá a szolgáltatás- és gazdakonzolokhoz.

2.4. követelmény

A PCI DSS hatókörébe tartozó rendszerösszetevők leltárának karbantartása.

Az Ön feladatai

Az architektúrában használt összes Azure-erőforrást megfelelően kell címkézni. A címkék segítenek az adatbesorolásban, és jelzik, hogy a szolgáltatás hatókörön belül vagy hatókörön kívül van-e. Az aprólékos címkézés lehetővé teszi az erőforrások lekérdezését, a leltár megőrzését, a költségek nyomon követését és a riasztások beállítását. A dokumentáció pillanatképét is rendszeresen karbantartja.

Kerülje a hatókörön belüli vagy a hatókörön kívüli erőforrások címkézését részletes szinten. A megoldás fejlődésével a hatókörön kívüli erőforrások akkor is hatókörön belülivé válhatnak, ha közvetett módon kommunikálnak vagy a kártyatulajdonos adataival szomszédosak. Ezek az erőforrások naplózás alatt állnak, és az audit során egy reprezentatív minta részét képezhetik. Fontolja meg a címkézést magasabb szinten, az előfizetés és a fürt szintjén.

A címkézési szempontokról további információt az erőforrás-elnevezési és címkézési döntési útmutatóban talál.

Fürtön belüli objektumok címkézése Kubernetes-címkék alkalmazásával. Így rendszerezheti az objektumokat, kijelölhet egy objektumgyűjteményt és jelentésleltárat.

2.5. követelmény

Győződjön meg arról, hogy a szállítói alapértelmezett értékek és egyéb biztonsági paraméterek kezelésére vonatkozó biztonsági szabályzatok és működési eljárások dokumentálva vannak, használatban vannak és ismertek az összes érintett fél számára.

Az Ön feladatai

Kritikus fontosságú, hogy alapos dokumentációt tartson fenn a folyamatokról és szabályzatokról. A személyzetnek be kell tanítania az egyes Azure-erőforrások biztonsági funkcióit és konfigurációs beállításait. A szabályozott környezeteket üzemeltető személyeket ki kell oktatni, tájékoztatni és ösztönözni kell, hogy támogassák a biztonsági garanciákat. Ezek a lépések különösen fontosak minden olyan személy számára, aki széles körű rendszergazdai jogosultságot kap.

2.6. követelmény

A megosztott tárhelyszolgáltatóknak védenie kell az egyes entitások üzemeltetett környezetét és kártyatulajdonosi adatait.

Az Ön feladatai

Az Azure biztonsági garanciákat biztosít minden megosztott üzemeltetett környezeti összetevőhöz. Erősen ajánlott az AKS-csomópontokat dedikált gazdagépként kezelni ehhez a számítási feladathoz. Ez azt jelzi, hogy minden számításnak egyetlen bérlői modellben kell lennie, és nem szabad megosztania más, esetleg üzemeltetett számítási feladatokkal.

Ha az Azure-infrastruktúra szintjén teljes számítási elkülönítésre van szükség, azure-beli dedikált gazdagépet adhat hozzá egy Azure Kubernetes Service-fürthöz (AKS). Ez az ajánlat a számítási feladathoz dedikált fizikai kiszolgálókat biztosít, így az AKS-csomópontokat közvetlenül ezekbe a kiépített gazdagépekbe helyezheti. Ez az architektúraválasztás jelentős költségvonzatokkal rendelkezik, és gondos kapacitástervezést igényel. Ez a legtöbb forgatókönyv esetében nem jellemző.

Következő lépések

A tárolt kártyaőrzők adatainak védelme. A kártyaőrző adatok átvitelének titkosítása nyílt, nyilvános hálózatokon.

Kapcsolódó erőforrások

• Az Azure Kubernetes Service (AKS) architektúra tervezése
• A PCI-DSS 3.2.1-hez készült AKS-szabályozott fürt bemutatása (9. rész)
• A PCI-DSS 3.2.1 AKS-szabályozott fürt architektúrája (9. rész)
• Azure Kubernetes Service-fürt alaparchitektúrája
• AKS-alapkonfiguráció többrégiós fürtökhöz