Zabezpečení dat v regulovaném clusteru AKS pro PCI-DSS 3.2.1 (část 4 z 9)

Tento článek popisuje aspekty clusteru Azure Kubernetes Service (AKS), který spouští úlohu v souladu se standardem PCI-DSS 3.2.1 ( Payment Card Industry Data Security Standard).

Tento článek je součástí série článků. Přečtěte si úvod.

Tato architektura a implementace se zaměřují na infrastrukturu, nikoli úlohy. Tento článek obsahuje obecné aspekty a osvědčené postupy, které vám pomůžou při rozhodování o návrhu. Postupujte podle požadavků v oficiální normě PCI-DSS 3.2.1 a podle potřeby použijte tento článek jako další informace.

Ochrana dat držitelů karet

Požadavek 3 – Ochrana uložených dat držitelů karet

Vaše odpovědnosti

Požadavek 4 – Šifrování přenosu dat držitelů karet napříč otevřenými veřejnými sítěmi

Vaše odpovědnosti

Požadavek 3.1

Udržujte úložiště dat držitelů karet na minimum implementací zásad uchovávání a odstraňování dat, postupů a procesů, které zahrnují alespoň následující informace pro všechna data držitelů karet (CHD):

• Omezení objemu a doby uchovávání dat na dobu, která se vyžaduje pro zákonné, regulační a obchodní požadavky
• Procesy bezpečného odstranění dat, pokud už nejsou potřeba
• Specifické požadavky na uchovávání dat držitelů karet
• Čtvrtletní proces identifikace a bezpečného odstranění uložených dat držitelů karet, které překračují definované uchovávání.

Vaše odpovědnosti

Neukládejte stav v clusteru AKS. Pokud se rozhodnete uložit CHD, prozkoumejte možnosti zabezpečeného úložiště. Mezi možnosti patří Azure Storage pro úložiště souborů nebo databáze, jako je Azure SQL Database nebo Azure Cosmos DB.

Dodržujte výhradně standardní pokyny týkající se toho, jaký druh CHD lze uložit. Definujte zásady uchovávání dat na základě vašich obchodních požadavků a typu použitého úložiště. Mezi klíčové aspekty patří:

• Jak a kde jsou uložená data?
• Jsou uložená data šifrovaná?
• Jaká je doba uchovávání?
• Jaké akce jsou povoleny během doby uchovávání?
• Jak odstraníte uložená data po uplynutí doby uchovávání?

Některé z těchto možností mají zásady správného řízení. Předdefinované zásady Azure vynucují tyto volby. Můžete například omezit typy svazků na podech clusteru nebo zakázat operace zápisu v kořenovém systému souborů.

Zkontrolujte tento seznam definic zásad a použijte je v clusteru, pokud je to možné.

Možná budete muset dočasně ukládat data do mezipaměti. Doporučujeme chránit data uložená v mezipaměti, když se přesunou do řešení úložiště. Zvažte povolení funkce šifrování na základě hostitele v AKS. Tím se šifrují data uložená na virtuálních počítačích uzlů. Další informace najdete v tématu Šifrování na základě hostitele ve službě Azure Kubernetes Service (AKS). Povolte také integrovanou zásadu Azure, která vyžaduje šifrování dočasných disků a mezipaměti pro fondy uzlů.

Při výběru technologie úložiště prozkoumejte funkce uchovávání informací. Azure Blob Storage například poskytuje zásady uchovávání informací na základě času. Další možností je implementovat vlastní řešení, které odstraňuje data podle zásad uchovávání informací. Příkladem je správa životního cyklu dat (DLM), která spravuje aktivity životního cyklu dat. Řešení bylo navrženo se službami, jako jsou Azure Data Factory, Microsoft Entra ID a Azure Key Vault.

Další informace najdete v tématu Správa životního cyklu dat pomocí služby Azure Data Factory.

Požadavek 3.2

Po autorizaci neukládejte citlivá ověřovací data (i když jsou zašifrovaná). Při přijetí citlivých ověřovacích dat vykreslujte všechna data neopravitelná po dokončení procesu autorizace.

Vaše odpovědnosti

(PLATÍ PRO: Požadavek 3.2.1, požadavek 3.2.2, požadavek 3.2.3)

Zpracování a ochrana dat je nad rámec této architektury. Tady je několik obecných aspektů.

Podle standardu se citlivá ověřovací data skládají z úplného sledování dat, ověřovacího kódu nebo hodnoty karty a dat PIN kódu. V rámci zpracování CHD se ujistěte, že ověřovací data nejsou ve zdrojích, jako jsou:

• Protokoly, které se z podů vygenerují.
• Rutiny zpracování výjimek
• Názvy souborů.
• Mezipaměť.

Jako obecné pokyny by obchodníci neměli tyto informace ukládat. Pokud potřebujete zdokumentovat obchodní odůvodnění.

Požadavek 3.3

Mask PAN při zobrazení (prvních šest a posledních čtyř číslic je maximální počet číslic, které se mají zobrazit), aby celý pan viděli jenom pracovníci s legitimní obchodní potřebou.

Vaše odpovědnosti

Číslo primárního účtu (PAN) se považuje za citlivá data a musí být zabráněno expozici těmto datům. Jedním ze způsobů je zmenšení zobrazených číslic maskováním.

Neimplementujte maskování dat v úloze. Místo toho použijte konstruktory na úrovni databáze. Řada služeb Azure SQL, včetně Azure Synapse Analytics, podporuje dynamické maskování dat, což snižuje vystavení na aplikační vrstvě. Je to funkce zabezpečení založená na zásadách, která definuje, kdo může zobrazit nemaskovaná data a kolik dat je vystaveno maskováním. Integrovaná metoda maskování platební karty zveřejňuje poslední čtyři číslice určených polí a přidá konstantní řetězec jako předponu ve formě platební karty.

Další informace najdete v tématu Dynamické maskování dat.

Pokud potřebujete do clusteru přenést nemaskovaná data, maskujte co nejdříve.

Požadavek 3.4

Vykreslovat pan nečitelný kdekoli, kde je uložený (včetně přenosných digitálních médií, záložních médií a protokolů) pomocí některého z následujících přístupů:

• Jednosměrné hodnoty hash založené na silné kryptografii (hodnota hash musí být celá hodnota PAN)
• Zkrácení (hodnotu hash nelze použít k nahrazení zkráceného segmentu pan).
• Indexové tokeny a podložky (podložky musí být bezpečně uložené)
• Silná kryptografie s přidruženými procesy a postupy správy klíčů.

Vaše odpovědnosti

Pro tento požadavek možná budete muset v úloze použít přímou kryptografii. Pokyny k PCI DSS doporučuje používat algoritmy testované v oboru, aby se vystavily útokům z reálného světa. Nepoužívejte vlastní šifrovací algoritmy.

Tyto požadavky splňují také příslušné techniky maskování dat. Zodpovídáte za maskování všech dat primárního účtu (PAN). Řada služeb Azure SQL, včetně Azure Synapse Analytics, podporuje dynamické maskování dat. Viz požadavek 3.3.

Ujistěte se, že pan není vystavený jako součást procesů pracovního postupu. Tady je několik aspektů:

• Zachovejte protokoly PAN mimo protokoly, protokoly pracovního postupu i (očekávané nebo neočekávané) protokoly zpracování výjimek. Toky diagnostických dat, jako jsou hlavičky HTTP, také nesmí tato data zveřejnit.

• Nepoužívejte pan jako vyhledávací klíč mezipaměti ani jako součást názvu souboru vygenerovaného tímto procesem.

• Vaši zákazníci můžou zadat pan v nepotřebných textových polích bez podoby. Ujistěte se, že jsou pro všechna textová pole volného formátu zavedeny procesy ověřování a detekce obsahu, které se podobají datům PAN.

Požadavek 3.4.1

Pokud se používá šifrování disku (místo šifrování databáze na úrovni souborů nebo sloupců), musí být logický přístup spravován samostatně a nezávisle na nativních mechanismech ověřování operačního systému a řízení přístupu (například bez použití databází místních uživatelských účtů nebo obecných přihlašovacích údajů k síti). Dešifrovací klíče nesmí být přidružené k uživatelským účtům.

Vaše odpovědnosti

Obecně platí, že neukládáte stav v clusteru AKS. Použijte externí úložiště dat, které podporuje šifrování na úrovni modulu úložiště.

Všechna uložená data ve službě Azure Storage se šifrují a dešifrují pomocí silné kryptografie. Microsoft spravuje přidružené klíče. Preferují se šifrovací klíče spravované vlastním systémem. Vždy zašifrujte mimo vrstvu úložiště a zapište jenom šifrovaná data do úložného média a zajistěte, aby klíče nikdy nepřisedly k vrstvě úložiště.

Se službou Azure Storage můžete také používat klíče spravované svým držitelem. Podrobnosti najdete v tématu Klíče spravované zákazníkem pro šifrování služby Azure Storage.

Podobné funkce jsou k dispozici pro databáze. Možnosti Azure SQL najdete v tématu Transparentní šifrování dat Azure SQL s klíčem spravovaným zákazníkem.

Ujistěte se, že klíče ukládáte do spravovaného úložiště klíčů (Azure Key Vault, modul hardwarového zabezpečení spravovaného hsM služby Azure Key Vault) a další.

Pokud potřebujete data dočasně ukládat, povolte funkci šifrování hostitele AKS a ujistěte se, že jsou data uložená na uzlech virtuálních počítačů zašifrovaná.

Požadavek 3.5

Zdokumentujte a implementujte postupy ochrany klíčů používaných k zabezpečení uložených dat držitelů karet před zveřejněním a zneužitím:

Vaše odpovědnosti

Tyto body jsou popsány v pododdílech:

• Udržujte si postup přístupu s nejnižšími oprávněními pro kryptografické klíče.
• Služba Azure Key Vault a Microsoft Entra ID jsou navržené tak, aby podporovaly požadavky na protokolování autorizace a auditu. Podrobnosti najdete v tématu Žádost o ověření pro Azure Key Vault.
• Chraňte všechny šifrovací klíče dat pomocí šifrovacího klíče klíče, který je uložený v kryptografickém zařízení.
• Pokud používáte klíče spravované sami (místo klíčů spravovaných Microsoftem), získáte proces a dokumentaci k údržbě úloh souvisejících se správou klíčů.

Požadavek 3.5.1

Další požadavek pouze na poskytovatele služeb: Udržujte zdokumentovaný popis kryptografické architektury, která zahrnuje:

• Podrobnosti o všech algoritmech, protokolech a klíčích používaných k ochraně dat držitelů karet, včetně síly klíče a data vypršení platnosti
• Popis použití klíče pro každý klíč
• Inventář všech hsM a dalších identifikátorů SCD používaných ke správě klíčů

Vaše odpovědnosti

Jedním ze způsobů, jak ukládat citlivé informace (klíče, připojovací řetězec a další), je použít nativní prostředek KubernetesSecret. Šifrování neaktivních uložených dat musíte explicitně povolit. Případně je uložte do spravovaného úložiště, jako je Azure Key Vault. Z těchto dvou přístupů doporučujeme použít službu spravovaného úložiště. Jednou z výhod je snížení režie při úlohách souvisejících se správou klíčů, jako je například obměně klíčů.

Azure ve výchozím nastavení používá klíče spravované Microsoftem pro všechna šifrovaná data na zákazníka. Některé služby však podporují pro šifrování také klíče spravované samospravou. Pokud k šifrování neaktivních uložených uložených klíčů používáte samospravované klíče, ujistěte se, že používáte proces a strategii, která zpracovává úlohy správy klíčů.

Jako součást dokumentace uveďte informace týkající se správy klíčů, jako je vypršení platnosti, umístění a podrobnosti plánu údržby.

Požadavek 3.5.2

Omezte přístup k kryptografickým klíčům na nejmenší počet potřebných správce.

Vaše odpovědnosti

Minimalizujte počet lidí, kteří mají přístup ke klíčům. Pokud používáte nějaká přiřazení rolí na základě skupin, nastavte opakovaný proces auditu pro kontrolu rolí, které mají přístup. Když se členové projektového týmu změní, účty, které už nejsou relevantní, musí být z oprávnění odebrány. Přístup by měli mít jenom ti správní lidé. Zvažte odebrání trvalých oprávnění ve prospěch přiřazení rolí JIT (just-in-time), aktivace role na základě času a aktivace rolí na základě schválení.

Požadavek 3.5.3

Ukládejte tajné klíče a privátní klíče používané k šifrování a dešifrování dat držitelů karet v jednom (nebo několika) následujících formulářích za všech okolností:

• Šifrované pomocí klíče pro šifrování klíčů, který je alespoň tak silný jako klíč pro šifrování dat a který je uložený odděleně od klíče šifrování dat.
• V rámci zabezpečeného kryptografického zařízení (například hardwarového (hostitelského) modulu zabezpečení (HSM) nebo zařízení s pts schváleným bodem interakce)
• Jako alespoň dvě klíčové součásti nebo klíčové sdílené složky s plnou délkou v souladu s metodou přijatou v odvětví

Vaše odpovědnosti

Úloha PCI-DSS 3.2.1 bude muset v rámci strategie ochrany neaktivních uložených dat používat více než jeden šifrovací klíč. Šifrovací klíč dat (DEK) se používá k šifrování a dešifrování CHD, ale zodpovídáte za další šifrovací klíč klíče (KEK), který chrání tento klíč DEK. Zodpovídáte také za to, že je klíč KEK uložený v kryptografickém zařízení.

Službu Azure Key Vault můžete použít k uložení DEK a k uložení klíče KEK použijte Azure Dedicated HSM. Informace o správě klíčů HSM najdete v tématu Co je Azure Dedicated HSM?.

Požadavek 3.6

Plně zdokumentovat a implementovat všechny procesy a postupy správy klíčů pro kryptografické klíče používané k šifrování dat držitelů karet, včetně následujících:

Vaše odpovědnosti

(PLATÍ PRO: Požadavek 3.6.1, požadavek 3.6.2, požadavek 3.6.3, požadavek 3.2.4)

Pokud používáte Azure Key Vault k ukládání tajných kódů, jako jsou klíče, certifikáty a připojovací řetězec, chraňte ho před neoprávněným přístupem. Microsoft Defender for Key Vault detekuje podezřelé pokusy o přístup a generuje výstrahy. Tato upozornění můžete zobrazit v programu Microsoft Defender for Cloud. Další informace najdete v programu Microsoft Defender for Key Vault.

Postupujte podle pokynů ke správě klíčů NIST . Podrobnosti najdete tady:

• Správa kryptografických klíčů
• SP 800-133 Rev. 2, doporučení pro generování kryptografických klíčů
• SP 800-57 Část 1 Rev. 5, doporučení pro správu klíčů

Viz také Microsoft Defender for Key Vault.

Požadavek 3.6.7

Prevence neoprávněného nahrazování kryptografických klíčů

Vaše odpovědnosti

• Povolte diagnostiku pro všechna úložiště klíčů. Použijte Azure Monitor pro Key Vault. Shromažďuje protokoly a metriky a odesílá je do služby Azure Monitor. Další informace najdete v tématu Monitorování služby trezoru klíčů pomocí služby Azure Monitor pro Key Vault.
• Udělte všem uživatelům oprávnění jen pro čtení.
• Nemáte oprávnění k umístění pro všechny instanční objekty pro správu. Místo toho použijte přiřazení rolí za běhu (JIT), aktivaci role na základě času a aktivaci rolí na základě schválení.
• Vytvořte centralizované zobrazení integrací protokolů a výstrah do řešení zabezpečení a správy událostí (SIEM), jako je Microsoft Sentinel.
• Proveďte akce s upozorněními a oznámeními, zejména u neočekávaných změn.

Požadavek 3.6.8

Požadavek na správce kryptografických klíčů, aby formálně potvrdili, že chápou a přijímají své klíčové odpovědnosti.

Vaše odpovědnosti

Udržujte dokumentaci, která popisuje účetní závazky stran zodpovědných při operacích správy klíčů.

Požadavek 3.7

Zajistěte, aby zásady zabezpečení a provozní postupy pro ochranu uložených dat držitelů karet byly zdokumentované, používané a známé všem postiženým stranám.

Vaše odpovědnosti

Vytvořte dokumentaci jako obecný příkaz a řadu aktuálních průvodců rolí pro všechny osoby. Proveďte školení a průběžné trénování nových zaměstnanců.

Je důležité udržovat důkladnou dokumentaci k procesům a zásadám. Několik týmů se účastní zajištění ochrany neaktivních uložených a přenášených dat. V dokumentaci poskytněte pokyny k rolím pro všechny osoby. Mezi tyto role patří SRE, zákaznická podpora, prodej, síťové operace, operace zabezpečení, softwaroví inženýři, správci databází a další. Pracovníci by měli být vyškoleni v pokynech k NIST a strategiích neaktivních uložených dat, aby byla sada dovedností aktuální. Požadavky na trénování jsou vyřešené v požadavcích 6.5 a požadavcích 12.6.

Požadavek 4.1

Používejte silné kryptografie a protokoly zabezpečení (například TLS, IPSEC, SSH atd.) k ochraně citlivých dat držitelů karet během přenosu přes otevřené veřejné sítě, včetně následujících:

Vaše odpovědnosti

Data držitelů karet (CHD), která se přepravují přes veřejný internet, musí být šifrovaná. Data musí být šifrovaná protokolem TLS 1.2 (nebo novějším) se sníženou podporou šifrování pro všechny přenosy. Nepodporuje přesměrování jiného typu než TLS na TLS u žádné služby přenosu dat.

Váš návrh by měl mít strategický řetězec bodů ukončení protokolu TLS. Při cestě dat přes segmenty směrování sítě udržujte protokol TLS na segmentech směrování, které vyžadují kontrolu paketů. Alespoň v prostředku příchozího přenosu dat clusteru je konečný bod ukončení protokolu TLS. Zvažte jeho další využití v rámci prostředků clusteru.

Použití Azure Policy k řízení vytváření prostředků:

• Odepřít vytvoření jakéhokoli prostředku příchozího přenosu dat, který není HTTPS.
• Zamítněte vytvoření jakékoli veřejné IP adresy nebo jakýchkoli veřejných nástrojů pro vyrovnávání zatížení ve vašem clusteru, abyste zajistili, že se webový provoz tuneluje přes bránu.

Další informace najdete v tématu Přehled šifrování Azure.

Požadavek 4.1.1

Zajistěte, aby bezdrátové sítě přenášely data držitelů karet nebo se připojily k datovému prostředí držitelů karet, použijte osvědčené postupy odvětví (například IEEE 802.11i) k implementaci silného šifrování pro ověřování a přenos.

Vaše odpovědnosti

Tato architektura a implementace nejsou navrženy tak, aby přes bezdrátová připojení dělaly místní ani cloudové transakce v podnikové síti. Důležité informace najdete v pokynech v oficiální normě PCI-DSS 3.2.1.

Požadavek 4.2

Nikdy neodesílejte nechráněné pany pomocí technologií zasílání zpráv koncových uživatelů (například e-mail, zasílání rychlých zpráv, SMS, chat atd.).

Vaše odpovědnosti

Pokud vaše úloha vyžaduje odesílání e-mailů, zvažte vytvoření brány karantény e-mailu. Toto ověření vám umožní zkontrolovat dodržování předpisů ve všech odchozích zprávách a zkontrolovat, že citlivá data nejsou zahrnutá. V ideálním případě byste měli tento přístup zvážit i pro zprávy zákaznické podpory.

Ověření by mělo být provedeno na úrovni úlohy a procesu řízení změn. Schvalovací brány by měly požadavkům rozumět.

Důležité informace najdete v pokynech v oficiální normě PCI-DSS 3.2.1.

Požadavek 4.3

Zajistěte, aby zásady zabezpečení a provozní postupy pro šifrování přenosů dat držitelů karet byly zdokumentované, používané a známé všem ovlivněným stranám.

Vaše odpovědnosti

Je důležité udržovat důkladnou dokumentaci k procesům a zásadám. To platí hlavně v případech, kdy spravujete zásady týkající se protokolu TLS (Transport Layer Security). Tady je několik oblastí:

• Veřejné internetové příchozí body. Příkladem je podpora brány Aplikace Azure šifrování TLS.
• Segmenty směrování sítě mezi hraniční sítí a pody úloh
• Šifrování pod-to-pod (pokud je implementováno). To může zahrnovat podrobnosti o konfiguraci sítě služeb.
• Pod do úložiště (pokud je součástí architektury).
• Pod externím službám, službám Azure PaaS, které používají protokol TLS, platební bránu nebo systém detekce podvodů.

Lidé, kteří pracují s regulovanými prostředími, musí být poučeni, informovaní a incentivizováni, aby podporovali bezpečnostní záruky. To je zvlášť důležité pro lidi, kteří jsou součástí procesu schvalování z hlediska zásad.

Další kroky

Chraňte všechny systémy před malwarem a pravidelně aktualizujte antivirový software nebo programy. Vývoj a údržba zabezpečených systémů a aplikací