Ochrana dat pro regulovaný cluster AKS pro PCI DSS 4.0.1

Tento článek popisuje aspekty ochrany dat pro cluster Azure Kubernetes Service (AKS), který spouští úlohu v souladu se standardem Zabezpečení dat odvětví platebních karet (PCI-DSS 4.0.1).

Tento článek je součástí série. 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ím PCI-DSS standardu 4.0.1 a případně použijte tento článek jako další informace.

Důležité

Pokyny a doprovodná implementace vycházejí ze základní architektury AKS, která je založená na hvězdicové síťové topologii. Virtuální síť centra obsahuje bránu firewall pro řízení odchozího provozu, provozu brány z místních sítí a třetí sítě pro údržbu. Paprsková virtuální síť obsahuje cluster AKS, který poskytuje prostředí CDE (card-holder) a hostuje úlohu PCI DSS.

Připravuje se implementace loga GitHubu: Základní cluster Azure Kubernetes Service (AKS) pro referenční implementaci regulovaných úloh pro PCI DSS 4.0.1 se v současné době aktualizuje a brzy bude k dispozici. Tato implementace předvede regulovanou infrastrukturu, která ilustruje použití různých kontrolních mechanismů sítě a zabezpečení ve vaší službě CDE. To zahrnuje obě síťové ovládací prvky nativní pro Azure a ovládací prvky nativní pro Kubernetes. Zahrne také aplikaci, která předvede interakce mezi prostředím a ukázkovou úlohou. Cílem tohoto článku je infrastruktura. Ukázka nebude indikovat skutečnou PCI-DSS úlohy 4.0.1.

Ochrana dat držitelů karet

Poznámka:

Tento článek byl aktualizován pro PCI DSS 4.0.1. Mezi hlavní změny patří podpora přizpůsobeného přístupu k ovládacím prvkům, rozšířenému vícefaktorovém ověřování (MFA), aktualizovaným požadavkům na kryptografii, rozšířenému monitorování a protokolování a zaměření se na nepřetržitou správu zabezpečení a rizik. Ujistěte se, že si projděte oficiální dokumentaci k PCI DSS 4.0.1 , kde najdete úplné podrobnosti a požadavky na budoucí data.

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 minimum implementací zásad uchovávání a odstraňování dat, postupů a procesů pro všechna úložiště držitelů karet (CHD).
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.
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.
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í silné kryptografie a procesů správy klíčů.
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.
Požadavek 3.6 Plně zdokumentujte a implementujte všechny procesy a postupy správy klíčů pro kryptografické klíče používané k šifrování dat držitelů karet.
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.

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 to, co je vyžadováno 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 identifikace a bezpečného odstranění uložených dat držitelů karet, které překračují definované uchovávání.

Vaše povinnosti (PCI DSS 4.0.1)

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. PCI DSS 4.0.1 umožňuje přizpůsobený přístup k plnění cílů zabezpečení, ale musíte zdokumentovat a odůvodnit všechny alternativní kontroly.

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 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. PCI DSS 4.0.1 zdůrazňuje nepřetržité monitorování a pravidelné hodnocení rizik pro všechny procesy ukládání a uchovávání dat.

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

Zpracování a ochrana dat je problém s úlohami a 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 vystavená ve zdrojích, jako jsou protokoly, rutiny zpracování výjimek, názvy souborů nebo mezipaměti. PCI DSS 4.0.1 vyžaduje rozšířené monitorování a protokolování k detekci a reakci na neoprávněný přístup nebo ukládání citlivých ověřovacích dat, včetně:

  • Protokoly, které se z podů vygenerují.
  • Rutiny zpracování výjimek
  • Názvy souborů.
  • Skrýše.

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. PCI DSS 4.0.1 objasňuje požadavky na maskování a umožňuje přizpůsobený přístup, pokud je odůvodněn a zdokumentovaný.

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, co nejdříve maskujte.

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. PCI DSS 4.0.1 aktualizuje kryptografické požadavky tak, aby odpovídaly vyvíjejícím se oborovým standardům. Používejte pouze algoritmy testované a schválené v oboru (například AES, RSA atd.) a vyhněte se vlastním šifrovacím algoritmům. Ujistěte se, že jsou kryptografické ovládací prvky nepřetržitě monitorované a testované.

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. PCI DSS 4.0.1 vyžaduje, aby maskování a kryptografické ovládací prvky byly zdokumentované a podléhaly nepřetržité kontrole.

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. PCI DSS 4.0.1 dále upřesňuje požadavky na správu klíčů a oddělení přístupu.

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íčů, jako je Azure Key Vault, Azure Managed HSM nebo řešení pro správu klíčů třetích stran.

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

Platí následující povinnosti:

  • 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 modulů hardwarového zabezpečení 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 na zákazníka pro všechna šifrovaná data. 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é. Pomocí kontrol přístupu k Microsoft Entra ID pravidelně kontrolujte členství ve skupinách.

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í. Zvažte například použití Privileged Identity Management.

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í:

  • Zašifrováno pomocí klíče zašifrované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 rámci zabezpečeného kryptografického zařízení (například hardwarového (hostitelského) modulu zabezpečení (HSM) nebo zařízení s bodem interakce schváleného PTS)
  • Jako alespoň dvě klíčové součásti s plnou délkou nebo klíčové sdílené složky v souladu s metodou přijatou v oboru.
Vaše odpovědnosti

Úloha PCI-DSS 4.0.1 bude v rámci strategie ochrany neaktivních uložených dat potřebovat 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í. PCI DSS 4.0.1 vyžaduje nepřetržité monitorování a dokumentaci všech klíčových aktivit správy.

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

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. PCI DSS 4.0.1 vyžaduje rozšířené monitorování a upozorňování pro všechny systémy správy klíčů.

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

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í ke správě uživatelů ani objektů zabezpečení. 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 povinnosti stran zapojených do operací 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 si udrželi přehled o svých dovednostech. 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: Šifrování přenosu dat držitelů karet napříč otevřenými a veřejnými sítěmi

Vaše odpovědnosti

Požadavek Odpovědnost
Požadavek 4.1 Používejte silné kryptografie a protokoly zabezpečení (například TLS 1.2 nebo vyšší, 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:
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.).
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.

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á pomocí protokolu TLS 1.2 nebo vyšší s podporou silné šifry pro všechny přenosy. Nepodporuje přesměrování přes protokol TLS na protokol TLS u žádné služby přenosu dat. PCI DSS 4.0.1 vyžaduje nepřetržité monitorování šifrovacích protokolů a pravidelné posouzení rizik, aby kryptografické kontroly zůstaly účinné.

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.

Diagram znázorňující šifrování dat

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. PCI DSS 4.0.1 umožňuje přizpůsobený přístup k ovládacím prvkům šifrování, pokud jsou odůvodněné a zdokumentované.

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ím PCI-DSS standardu 4.0.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ím PCI-DSS standardu 4.0.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). Dokumentace by měla obsahovat informace o aspektech, jako jsou:

  • Veřejné internetové příchozí body. Příkladem je podpora brány Aplikace Azure lication Gateway pro šifry 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

Implementujte komplexní kryptografii a řízení správy klíčů pro ochranu neaktivních uložených a přenášených dat držitelů karet.

Implementace kryptografie a správy klíčů

  • Poslední aktualizace v