Takže v podstatě to, co požadavek říká, je, že musíte každému serveru přiřadit jednu primární funkci.

Server, který jste popsali, zní, jako by spouštěl několik aplikací, které mohou uživatelé z produkce využít. To by bylo klasifikováno jako „aplikační“ server. Také jste však zmínili, že na tomto serveru je více aplikací, některé se CDE dotýkají nepřímo a jiné nikoli. I když by tento server měl mít jednu primární roli, přináší do úvahy ovládání aplikací, které se nedotýkají CDE.

Pokud bych to byl já, přesunul bych aplikace, které nemají komunikovat s CDE mimo toto pole a přesunout je na jiný server, pokud možno do jiného segmentu. Pokud nemáte segmentovanou síť (což byste opravdu měli, opravdu máte), pak je vše stejně v rozsahu, takže na této radě nezáleží.

Pravda o shodě s PCI-DSS je tato:

Jste v souladu s PCI-DSS, pokud váš QSA říká, že jste v souladu s PSI-DSS.

Jsem toho názoru, že rada PCI odvedla docela smradlavou práci, když nám poskytla velmi jasný a věcný standard, kterým se máme řídit, alespoň pokud jde o standardy. Jak již bylo řečeno, jedná se o jeden z těch zajímavých případů, kdy se zdá, že požadavek je s úmyslem trochu mimo.

Vezměte doslovný text z požadavku:

2.2.1 Implementujte pouze jednu primární funkci na server, abyste zabránili koexistenci funkcí vyžadujících různé úrovně zabezpečení na stejném serveru. (Například webové servery, databázové servery a DNS by měly být implementovány na samostatných serverech.)

Právě tam se říká, primární funkce, která vás může otevřít k některým neshodám. Dalo by se říci, že primárním účelem daného serveru je uložení databáze pro procesor, zatímco je také nakonfigurován tak, aby spouštěl modul pro podávání zpráv jako sekundární funkci.

Rada také produkuje další dokument s názvem „Navigating the PCI DSS v2.0“, který je k dispozici ke stažení na stejném místě jako samotný standard. Tento dokument se věnuje mnohem podrobnějším informacím o každém požadavku a pokouší se vysvětlit záměr , který je za nimi.

Záměrem je zajistit, aby standardy konfigurace systému vaší organizace a související procesy řešily funkce serveru, které musí mít různé úrovně zabezpečení, nebo které mohou představovat slabiny zabezpečení pro jiné funkce na stejném serveru.

Dobře, super, to se mi líbí. Říká nám, že se snaží oddělit na základě úrovně zabezpečení dotyčných dat. V teorii tedy, pokud máte webovou aplikaci, která umožňuje přímý přístup k databázi obsahující data držitelů karet, a jediní lidé, kteří mají přístup k této nejvyšší citlivosti dat mít přístup k webové aplikaci, jeden by mohl být schopen hostit je oba ve stejném systému při zachování souladu. Pokud však existuje nástroj pro podávání zpráv, který poskytuje statistické údaje o transakcích, ale ne samotná data o držiteli karty, a má k nim přístup jiná skupina lidí? Ano, budete to chtít rozdělit.

Je však velmi pravděpodobné, že poslední věcí, kterou byste chtěli dělat, je krájení chloupků na menší a menší kousky pomocí QSA. Typicky zastávaný názor tedy je:

Informace uvedené výše v žádném případě nelze považovat za oficiální radu a jsou poskytovány bez oprávnění záruka, dobrá víra nebo přiměřený příjem ranní kávy. Uvedená prohlášení nepředstavují názory rady PCI, žádného QSA / ASV, mého zaměstnavatele, vašeho zaměstnavatele, tohoto webu, žádného jiného webu ani poskytovatele internetových služeb, na kterém tuto zprávu prohlížíte.

Protože se PCI nevztahuje na konkrétní aplikaci, nýbrž na celé prostředí , dalo by se říci, že všechny aplikace považuje za součást stejného systému.

To znamená - vrstva aplikačního serveru je „jedinou primární funkcí“ pro všechny části systému (tj. aplikace), bez ohledu na to, kolik jich je - za předpokladu, že jsou všechny součástí příslušné systému a to vše na stejné úrovni důvěryhodnosti.

Takže pokud máte nějaké interní aplikace, nebo např. vaše veřejné webové stránky, které nemají nic společného s kreditními kartami - měli byste je přesunout do jiného prostředí (tj. na server, síť atd.), jinak by v nejlepším případě splňovaly požadavky PCI - a nechcete že. V nejhorším případě byste tento požadavek nesplnili.

To znamená, Pamatujte, že se stejně musíte poradit se svým QSA . Potřebovali byste, aby se k tomu odhlásil, a stále existuje určitý prostor pro interpretaci založenou na vašem konkrétním kontextu.

Je „aplikační server“ „jednou primární funkcí“ nebo musí být „program x server“, „program y server“ atd.?

To je na interpretaci na základě toho, jak související a podobné programy X a Y jsou. Tento druh otázek směřuje k šedé oblasti, kde se QSA liší a vy lovíte kolem pro kompenzaci ovládacích prvků.

Podívejte se však na záměr pravidla - chce, abyste si ponechali různé „úrovně zabezpečení“ oddělené.

Takže pokud máte spoustu aplikací, které všechny komunikují se stejnými webovými službami nebo databází (na jiném serveru s vlastními ovládacími prvky) pomocí stejných pověření, mohlo by smysl je považovat za jednu funkci. Pokud útočník kompromitoval program X a to mu umožnilo kompromitovat program Y, který byl na stejném serveru, dostane to tím, že by kompromitovalo program X, co ještě nemělo?

Tyto aplikace také mají různé role skupin a přiřazená oprávnění v rámci nich a slouží různým oddělením.

Díky tomu zní, jako byste skutečně měli různé funkce a různé úrovně zabezpečení na serveru.

Některé z nich interagují nepřímo s aplikací, ve které se nacházejí data držitele karty, jiné ne.

Jaká je povaha nepřímé interakce? Pokud interakce prochází bránou (něco, co funguje jako efektivní kontrolní bod), který není v CDE, můžete server zcela vyloučit z rozsahu PCI.

Pokud se nemůžete vyhnout tomu, abyste měli server v rozsahu, důrazně doporučuji přesunout aplikace na něm, které nemusí komunikovat s CDE, na jiný server, který nebude v rozsahu.