Tento článek popisuje důležité informace pro cluster 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, a ne na úlohu. Tento článek obsahuje obecné informace a osvědčené postupy, které vám pomůžou při rozhodování o návrhu. Postupujte podle požadavků v oficiálním standardu PCI-DSS 3.2.1 a použijte tento článek jako další informace, kde je to k dispozici.
Důležité
Doprovodné pokyny a implementace staví na základní architektuře AKS. Tato architektura je založená na topologii centra a paprsku. Centrální virtuální síť obsahuje bránu firewall pro řízení výchozího provozu, provoz brány z místních sítí a třetí síť pro údržbu. Paprsková virtuální síť obsahuje cluster AKS, který poskytuje datové prostředí držitelů karet (CDE) a hostuje PCI DSS úlohy.
loga GitHub: Azure Kubernetes Service (AKS) Baseline Cluster for Regulated Workloads (Základní cluster AKS) pro regulovaný úlohy ukazuje regulovanou infrastrukturu. Tato implementace poskytuje aplikaci mikroslužeb. Součástí je , která vám pomůže prožít infrastrukturu a znázorní síťové a bezpečnostní prvky. Aplikace nepředstavuje ani neimplementuje skutečnou PCI DSS úlohy.
Ochrana dat držitelů karet
Požadavek 3 — Ochrana uložených dat držitelů karet
Vaše odpovědnosti
| Požadavek | Odpovědnost |
|---|---|
| Požadavek 3.1 | Udržujte úložiště dat držitelů karet na minimu implementací zásad uchovávání a vyřazení dat, postupů a procesů, které zahrnují alespoň následující postupy pro všechna úložiště dat držitelů karet: |
| Požadavek 3.2 | Po autorizaci neukládejte citlivá ověřovací data (i když jsou zašifrovaná). Pokud jsou přijata citlivá ověřovací data, vykreslí se po dokončení procesu autorizace všechna data, která se nespravují. |
| Požadavek 3.3 | Mask PAN when displayed (Mask PAN when displayed ( prvních šest a posledních čtyř číslic je maximální počet číslic, které se mají zobrazit) tak, aby úplné PAN viděli jenom pracovníci s oprávněnými obchodními potřebumi. |
| Požadavek 3.4 | Pomocí libovolného z následujících přístupů vykreslte PAN nečitelným všude, kde je uložený (včetně přenositelného digitálního média, záložního média a protokolů): |
| Požadavek 3.5 | Zdokumentujte a implementujte postupy pro ochranu klíčů používaných k zabezpečení uložených dat držitelů karet před zveřejněním a zneužitím: |
| Požadavek 3.6 | Úplné zdokumentování a implementace všech procesů správy klíčů a postupů pro kryptografické klíče používané k šifrování dat držitelů karet, včetně následujících: |
| Požadavek 3.7 | Zajistěte, aby zásady zabezpečení a provozní postupy pro ochranu uložených dat držitelů karet byly zdokumentovány, používat a známé všem ovlivněným stranám. |
Požadavek 4 — Šifrování přenosu dat držitelů karet mezi otevřenými veřejnými sítěmi
Vaše odpovědnosti
| Požadavek | Odpovědnost |
|---|---|
| Požadavek 4.1 | K ochraně citlivých dat držitelů karet během přenosu přes otevřené veřejné sítě použijte silné kryptografické a zabezpečovací protokoly (například TLS, IPSEC, SSH atd.), včetně následujících: |
| Požadavek 4.2 | Nikdy neodesílejte nechráněné PAN technologiemi zasílání zpráv koncových uživatelů (například e-mail, rychlé zprávy, SMS, chat atd.). |
| Požadavek 4.3 | Zajistěte, aby zásady zabezpečení a provozní postupy pro šifrování přenosů dat držitelů karet byly zdokumentovány, používat a známé všem ovlivněným stranám. |
Požadavek 3.1
Udržujte úložiště dat držitelů karet na minimu implementací zásad uchovávání a vyřazení dat, postupů a procesů, které zahrnují alespoň následující postupy pro všechna úložiště dat držitelů karet:
- Omezení množství úložiště dat a doby uchovávání na dobu, která je potřebná pro zákonné, zákonné a obchodní požadavky
- Procesy bezpečného odstranění dat, pokud už je nepotřebujete
- Specifické požadavky na uchovávání dat držitelů karet
- Čtvrtletní proces pro identifikaci a bezpečné 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 ukládat CHD, prozkoumejte možnosti zabezpečeného úložiště. Mezi možnosti Azure Storage úložiště souborů nebo databází, jako jsou 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, které je třeba vzít v úvahu, jsou:
- Jak a kde jsou data uložená?
- Jsou uložená data zašifrovaná?
- Jaká je doba uchovávání?
- Jaké akce jsou povolené 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í se obchytnou zásadami správného řízení. Integrované zásady Azure tyto volby vynucuje. Můžete například omezit typy svazků na podech clusteru nebo odepřít operace zápisu v kořenovém systému souborů.
Prohlédněte si tento seznam definic zásad a případně je použijte v clusteru.
Možná budete muset dočasně ukládat data do mezipaměti. Při přesunu dat do úložiště doporučujeme data uložená v mezipaměti chránit. Zvažte povolení funkce šifrování na základě hostitele v AKS. Tím se zašifrují data uložená na virtuálních počítačech uzlů. Další informace najdete v tématu Šifrování na základě hostitele v Azure Kubernetes Service (AKS). Povolte také předdefinované zásady Azure, které vyžadují š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í. Například Azure Blob Storage zásady uchovávání informací podle času. Další možností je implementovat vlastní řešení, které odstraní 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, Azure Active Directory (Azure AD) a Azure Key Vault.
Další informace najdete v tématu Správa životního cyklu dat pomocí Azure Data Factory.
Požadavek 3.2
Po autorizaci neukládejte citlivá ověřovací data (i když jsou zašifrovaná). Pokud jsou přijata citlivá ověřovací data, vykreslí se po dokončení procesu autorizace všechna data, která se nespravují.
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 přesahuje rozsah této architektury. Tady je několik obecných hledisek.
Na základě standardních citlivých ověřovacích dat se skládají z dat úplného sledování, ověřovacího kódu karty nebo hodnoty a dat PIN kódu. V rámci zpracování CHD se ujistěte, že ověřovací data nejsou zveřejněná ve zdrojích, jako jsou:
- Protokoly generované z podů.
- Rutiny zpracování výjimek.
- Názvy souborů.
- Mezipaměti.
Jako obecné pokyny by obchodníci neměli tyto informace ukládat. Pokud existuje potřeba dokument, obchodní odůvodnění.
Požadavek 3.3
Mask PAN when displayed (Mask PAN when displayed ( prvních šest a posledních čtyř číslic je maximální počet číslic, které se mají zobrazit) tak, aby úplné PAN viděli jenom pracovníci s oprávněnými obchodními potřebumi.
Vaše odpovědnosti
Primární číslo účtu (PAN) se považuje za citlivá data a je nutné jim zabránit. Jedním ze způsobů je zmenšování zobrazených číslic prostřednictvím maskování.
Do úlohy neimplementujte maskování dat. Místo toho použijte konstruktory na úrovni databáze. služba azure SQL, včetně služby azure Synapse Analytics, podporuje dynamické maskování dat, která omezuje expozici v 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 se zveřejňuje prostřednictvím maskování. Vestavěná metoda maskování kreditní karty zpřístupňuje poslední čtyři číslice určených polí a jako předponu ve formě platební karty přidá konstantní řetězec.
Další informace najdete v tématu dynamické maskování dat.
Pokud potřebujete do svého clusteru přenést nemaskovaná data, co nejdříve.
Požadavek 3,4
Vykreslení pánev je nečitelná kdekoli, kde je uložená (včetně přenosných digitálních médií, záložních médií a v protokolech) 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é POSUNUTí)
- Zkrácení (algoritmus hash se nedá použít k nahrazení zkráceného segmentu posouvání).
- Tokeny a překladače indexů (musí být bezpečně uložené)
- Silné šifrování s přidruženými procesy a postupy správy klíčů.
Vaše odpovědnosti
Pro tento požadavek možná budete muset použít přímo kryptografii v rámci úlohy. Pokyny pro PCI DSS jsou doporučeny pro obory testované v oboru, aby byly v reálném čase až do reálného světa. Nepoužívejte vlastní šifrovací algoritmy.
Tyto požadavky také splňují vhodné techniky maskování dat. Zodpovídáte za maskování všech primárních dat účtu (POSUNu). služba azure SQL, včetně služby azure Synapse Analytics, podporuje dynamické maskování dat. Viz požadavek 3,3.
Ujistěte se, že se pánev nezveřejňuje jako součást procesů pracovního postupu. Tady je několik důležitých informací:
Udržujte si co nejdálení protokolů, protokoly pracovních postupů i (očekávané i neočekávané) protokoly zpracování výjimek. Také toky dat diagnostiky, například hlavičky protokolu HTTP, nesmí vystavovat tato data.
Nepoužívejte PAN jako klíč vyhledávání mezipaměti ani jako součást jakéhokoli názvu souboru vygenerovaného tímto procesem.
Vaši zákazníci můžou v bezplatných textových polích bez výzvy zadat POSUNUTí. Zajistěte, aby byly k dispozici procesy ověřování obsahu a zjišťování pro libovolná textová pole s volným formulářem, a tím všechen obsah, který se podobá datům posouvání.
3.4.1 požadavku
Pokud se používá šifrování disku (místo šifrování databáze na úrovni souborů nebo sloupců), musí být logický přístup spravovaný samostatně a nezávisle na nativním ověřování operačního systému a mechanismech řízení přístupu (například při nepoužití místních databází uživatelských účtů nebo obecných přihlašovacích údajů k síti). Dešifrovací klíče nesmí být přidruženy k uživatelským účtům.
Vaše odpovědnosti
Jako obecné pravidlo neukládejte stav do clusteru AKS. Použijte externí úložiště dat, které podporuje šifrování na úrovni úložiště.
všechna uložená data v Azure Storage jsou šifrovaná a dešifrována pomocí silné kryptografie. Microsoft spravuje přidružené klíče. Upřednostňovaným šifrovacím klíčům, které jsou samoobslužně spravované. Vždy Zašifrujte mimo vrstvu úložiště a zapište do úložného média jenom zašifrovaná data a zajistěte, aby klíče nikdy nesousedí s vrstvou úložiště.
pomocí Azure Storage můžete použít taky samoobslužné klíče. podrobnosti najdete v tématu klíče spravované zákazníkem pro Azure Storage šifrování.
Pro databáze jsou k dispozici podobné funkce. možnosti SQL azure najdete v tématu azure SQL transparentní šifrování dat s klíčem spravovaným zákazníkem.
Ujistěte se, že jste klíče ukládali do úložiště spravovaného klíče (Azure Key Vault, Azure Key Vault modulu hardwarového zabezpečení (HSM) a dalších).
Pokud potřebujete dočasně ukládat data, povolte funkci šifrování hostitele AKS a ujistěte se, že data uložená na uzlech virtuálních počítačů jsou šifrovaná.
Požadavek 3,5
Zdokumentujte a implementujte postupy, které chrání klíče používané k zabezpečení uložených dat pro držitele na základě odhalení a zneužití:
Vaše odpovědnosti
Tyto body jsou popsány v částech:
- Udržujte přístup k kryptografickým klíčům s přístupem s nejnižšími oprávněními.
- Azure Key Vault a Azure Active Directory jsou navržené tak, aby podporovaly požadavky na ověřování a protokolování auditu. Podrobnosti najdete v tématu žádosti o ověření pro Azure Key Vault.
- Chraňte všechny šifrovací klíče dat pomocí klíčového šifrovacího klíče, který je uložený v kryptografickém zařízení.
- Pokud používáte samoobslužné klíče (místo klíčů spravovaných Microsoftem), získáte proces a dokumentaci pro údržbu úloh souvisejících se správou klíčů.
Požadavek 3.5.1
Další požadavky pro poskytovatele služeb: Udržujte dokumentovaný popis kryptografické architektury, která zahrnuje:
- Podrobnosti o všech algoritmech, protokolech a klíčích používaných k ochraně dat držitele klíčů, včetně síly klíče a data vypršení platnosti
- Popis použití klíče pro každý klíč
- Inventarizace všech HSM a dalších SCDs 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ězce a další), je použít nativní Secret prostředek Kubernetes. Je nutné explicitně povolit šifrování v klidovém umístění. Případně je uložte do spravovaného úložiště, například Azure Key Vault. Z těchto dvou přístupů doporučujeme použít spravovanou službu úložiště. Jednou z výhod je nižší nároky na úlohy související se správou klíčů, jako je například střídání klíčů.
Ve výchozím nastavení používá Azure pro všechna zašifrovaná data na zákazníka klíče spravované Microsoftem. Některé služby však podporují i samy spravované klíče pro šifrování. Pokud používáte samoobslužné klíče pro šifrování v klidovém umístění, ujistěte se, že máte v úvahu proces a strategii, které zpracovávají úlohy správy klíčů.
Jako součást vaší dokumentace uveďte informace týkající se správy klíčů, jako je například 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 nezbytných starají.
Vaše odpovědnosti
Minimalizujte počet uživatelů, kteří mají přístup ke klíčům. Pokud používáte přiřazení rolí založených na skupině, nastavte opakovaný proces auditu pro kontrolu rolí, které mají přístup. Když se členové projektového týmu změní, účty, které již nejsou relevantní, musí být odebrány z oprávnění. Přístup by měli mít jenom oprávnění lidé. Zvažte odebrání stálých oprávnění za použití přiřazení role JIT (just-in-time), aktivace rolí na základě času a aktivace rolí založenou na schválení.
3.5.3 požadavku
Ukládejte tajné a soukromé klíče, které se používají k šifrování/dešifrování dat držitele karty v jedné (nebo více) následujících formulářů, a to za všech okolností:
- Zašifrováno klíčem šifrovacího klíče, který je alespoň tak silný jako klíč pro šifrování dat a který je uložen odděleně od klíče pro šifrování dat.
- V zabezpečeném kryptografickém zařízení (například modul hardwarového zabezpečení (hostitele) nebo PTS zařízení typu Point-to-of-ininterakce)
- Jak v souladu s metodou přijatou v oboru, tak jak alespoň dvě klíčové komponenty s plnou délkou nebo sdílené složky.
Vaše odpovědnosti
Úloha rozhraní PCI-DSS 3.2.1 bude muset použít více než jeden šifrovací klíč jako součást strategie ochrany na základě dat. K šifrování a dešifrování CHD se používá šifrovací klíč dat (klíč DEK), ale zodpovídáte za další klíč šifrovacího klíče (KEK) k ochraně tohoto klíč dek. Zodpovídáte také za zajištění, že KEK je uložený v kryptografickém zařízení.
Pomocí Azure Key Vault můžete ukládat klíč DEK a používat vyhrazené modul HSM Azure k ukládání KEK. Informace o správě klíčů HSM najdete v tématu co je vyhrazený modul HSM Azure?.
Požadavek 3,6
Plně zdokumentujte a implementujte všechny procesy a postupy správy klíčů pro kryptografické klíče, které slouží k šifrování dat držitele, včetně následujících:
Vaše odpovědnosti
(Platí pro: 3.6.1 požadavků, 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 klíčů, jako jsou klíče, certifikáty a připojovací řetězce, Chraňte je před neoprávněným přístupem. Azure Defender pro Key Vault detekuje podezřelé pokusy o přístup a generuje výstrahy. Tyto výstrahy můžete zobrazit v Azure Security Center. Další informace najdete v tématu Azure Defender pro Key Vault.
Postupujte podle pokynů NIST ke správě klíčů. Podrobnosti najdete tady:
- Správa kryptografických klíčů.
- SP 800-133 rev. 2, doporučení pro generování kryptografického klíče
- SP 800-57 část 1 Rev. 5, doporučení pro správu klíčů
Viz také Azure Defender pro Key Vault.
3.6.7 požadavku
Prevence neoprávněného nahrazení kryptografických klíčů
Vaše odpovědnosti
- Povolte diagnostiku pro všechna úložiště klíčů. Pro Azure Monitor použijte Key Vault. Shromažďuje protokoly a metriky a odesílá je do Azure Monitor. Další informace najdete v tématu Monitorování služby trezoru klíčů pomocí Azure Monitor pro Key Vault.
- Udejte všem spotřebitelům oprávnění jen pro čtení.
- Nemáte oprávnění ke všem objektům služby pro správu. Místo toho použijte přiřazení rolí za běhu (JIT), aktivaci rolí na základě času a aktivaci role na základě schválení.
- Vytvořte centralizované zobrazení integrací protokolů a výstrah do řešení správy akcí a informací o zabezpečení (SIEM), jako je Azure Sentinel.
- Provádět akce s upozorněními a oznámeními, zejména v případě neočekávaných změn
Požadavek 3.6.8
Požadavek na správce kryptografického klíče, aby formálně potvrdil, že rozumí svým odpovědnostem za správce klíčů a přijal je.
Vaše odpovědnosti
Udržujte si dokumentaci, která popisuje zodpovědnosti stran zodpovědných za provoz 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 zdokumentovány, používat a známé všem ovlivněným stranám.
Vaše odpovědnosti
Vytvořte dokumentaci jako obecné prohlášení a řadu aktuálních průvodců rolemi pro všechny osoby. Trénování nových zaměstnanců a průběžné školení
Je velmi důležité udržovat důkladnou dokumentaci týkající se procesů a zásad. Několik týmů se účastní ochrany dat v klidových a přenosech. V dokumentaci uveďte pokyny k rolím pro všechny osoby. Role by měly zahrnovat SRE, zákaznickou podporu, prodej, síťový provoz, operace zabezpečení, softwarové inženýry, správce databází a další. Pracovníci by měli být natrénování v pokynech NIST a strategiích ostatních dat, aby měli tyto dovednosti aktuální. Požadavky na školení jsou vyřešené v požadavcích 6.5 a 12.6.
Požadavek 4.1
K ochraně citlivých dat držitelů karet během přenosu přes otevřené veřejné sítě používejte silné kryptografické a zabezpečovací protokoly (například TLS, IPSEC, SSH atd.), včetně následujících:
Vaše odpovědnosti
Data držitele karty (CHD), která prochádí veřejným internetem, musí být šifrovaná. Data musí být šifrovaná protokolem TLS 1.2 (nebo novějším) s omezenou podporou šifrování pro všechny přenosy. Nepodporuje přesměrování na TLS bez TLS u žádné služby přenosu dat.
Váš návrh by měl mít strategickou řetěz ukončovacích bodů protokolu TLS. Při přenosu dat přes segmenty směrování v síti udržujte protokol TLS v segmentech směrování, které vyžadují kontrolu paketů. Přinejmenším musí mít koncový bod ukončení protokolu TLS v prostředku příchozího přenosu dat clusteru. Zvažte jeho další použití v rámci prostředků clusteru.
Pomocí Azure Policy řízení vytváření prostředků:
- Odepřít vytvoření jakéhokoli prostředku příchozího přenosu dat bez HTTPS
- Zakažte vytvoření jakékoli veřejné IP adresy nebo veřejných nástrojů pro vyrovnávání zatížení v clusteru, abyste zajistili tunelování webového provozu přes vaši 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ě, které přenášejí data držitelů karet nebo připojily k prostředí dat držitelů karet, použijte osvědčené postupy v oboru (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 určené k provádění místních nebo podnikových transakcí mezi sítěmi a cloudy prostřednictvím bezdrátových připojení. Důležité informace najdete v pokynech v oficiálním standardu PCI-DSS 3.2.1.
Požadavek 4.2
Nikdy neodesílejte nechráněné PAN technologiemi zasílání zpráv koncových uživatelů (například e-mail, rychlé zprávy, 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í kontrolovat dodržování předpisů u všech odchozích zpráv a kontrolovat, jestli nejsou zahrnuta citlivá data. V ideálním případě byste tento přístup měli zvážit i u zpráv zákaznické podpory.
Ověření by se mělo provést na úrovni úlohy a procesu řízení změn. Schvalovací brány by měly tento požadavek pochopit.
Důležité informace najdete v pokynech v oficiálním standardu 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 zdokumentovány, používat a známé všem ovlivněným stranám.
Vaše odpovědnosti
Je velmi důležité udržovat důkladnou dokumentaci týkající se procesů a zásad. To platí hlavně v případě, že spravujete zásady týkající se protokolu TLS (Transport Layer Security). Tady jsou některé oblasti:
- Veřejné internetové body příchozího přenosu dat. Příkladem je Azure Application Gateway šifrování TLS.
- Segmenty směrování sítě mezi hraniční sítí a pody úloh.
- Šifrování mezi pody (pokud je implementováno). To může zahrnovat podrobnosti o konfiguraci sítě služeb.
- Z podu do úložiště (pokud je součástí architektury).
- Pod k externím službám, službám Azure PaaS, které používají tls, platební bránu nebo systém pro odhalování podvodů.
Lidé, kteří provozují regulovaná prostředí, musí být pouční, informovaní a incentivovaní, aby podpořili záruky zabezpečení. To je zvláště důležité pro lidi, kteří jsou součástí procesu schvalování z hlediska zásad.
Další
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í